Subject: Re: [PATCH] system: Allow distinguishing <mapped-device-type>s.

From: Ludovic Courtès <[email-masked]>
Date: Fri, 11 Apr 2025 10:27:50 +0200

Hello,

Tomas Volf <[email-masked]> skribis:

> Ludovic Courtès <[email-masked]> 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’.