[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#41143] [PATCH 1/2] mapped-devices: Allow target to be list of strin

From: Ludovic Courtès
Subject: [bug#41143] [PATCH 1/2] mapped-devices: Allow target to be list of strings
Date: Fri, 25 Sep 2020 18:20:51 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)


Mikhail Tsykalov <> skribis:


>>> While this looks like a good idea, doesn't this break code that
>>> implements mapped-device and assumes that target is a string. Suddenly
>>> passing a string to a mapped-device constructor results in a list
>>> passed to open/close. Also, what functions should do if they expect a
>>> string but get a list of them? Ignore everything but the first item?
>>> Implement mandatory check function? Doesn't this change push
>>> complexity out of mapped-device to implementations of it.
>> The intent of what I propose above is (1) to not break existing code,
>> and (2) to avoid duplicating checks and conversions at every call site.
>> #1 is achieved by providing a deprecated ‘mapped-device-target’
>> (singular) procedure, for example.
>> Does that make sense?
> I'm sorry if I didn't make myself clear, but it doesn't seem like
> open/close functions even use any mapped-device-* procedures, they
> just get passed source and target field directly. What I meant was
> this change will require changes to luks-device-mapping,
> raid-device-mapping and all other device mappings that users may have
> implemented in their local trees/config.

Ah yes, got it.

I tend to think it’s OK though, if we assume all the implementations are
in-tree, which would be consistent with the fact that the internals (how
to implement a mapped device type) are undocumented.


IOW, I think we must provide compatibility for users (people writing
their OS config, including perhaps service definitions) while leaving us
the ability to change internal interfaces.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]