GNU bug report logs - #70826
luks-device-mapping-with-options breaks bootloader

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Tomas Volf <~@wolfsden.cz>
Cc: Tadhg McDonald-Jensen <tadhgmister <at> gmail.com>, 45mg <45mg.writes <at> gmail.com>, 70826 <at> debbugs.gnu.org
Subject: bug#70826: [PATCH] system: Allow distinguishing <mapped-device-type>s.
Date: Fri, 11 Apr 2025 10:27:50 +0200

Hello,

Tomas Volf <~@wolfsden.cz> skribis:

> Ludovic Courtès <ludo <at> gnu.org> writes:

[...]

>> +++ b/gnu/system/mapped-devices.scm
>> @@ -83,6 +83,8 @@ (define-record-type* <mapped-device> %mapped-device
>>    (source    mapped-device-source)                ;string | list of strings
>>    (targets   mapped-device-targets)               ;list of strings
>>    (type      mapped-device-type)                  ;<mapped-device-kind>
>> +  (arguments mapped-device-arguments              ;list passed to open/close/check
>> +             (default '()))
>
> I do not think it is a good idea to expect the same identical list for
> all of the operations, so we would need arguments-open, arguments-close
> and arguments-check fields.  Other that that, this would work, sure.

Yeah I wondered about that but I thought that in the worst case the
operations could just ignore those arguments; from the user’s viewpoint,
that would keep the interface simple.

> Only thing I wonder about whether we should be apply-ing the list, or
> just passing it as a final arguments.  That would be a change in the
> calling convention, but all procedures could just be adjusted to take
> the extra argument.

It’s a backward-compatible change in the calling convention (nothing
changes for existing open/close/check methods that accept no keyword
arguments).

> One question would be how to handle if user passes the extra arguments
> to a procedure that is not prepared to handle them.  In your approach
> (apply) it would be a error due to wrong number of arguments, I am not
> sure whether that is ideal.  Maybe a warning would be better?  Not sure.
> Opinions?

Yes, you’d get a wrong-type-arg error, similar to what you have if you
pass #:random-number 42 in the ‘arguments’ field of a package.

It’s not ideal in terms of error reporting, but maybe good enough.

Another option would be for instance to always pass a key/value pair;
open/close/check methods would have to look up in that list for relevant
keys and could provide better error reporting, but the downside is extra
boilerplate in those methods.

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.