From: "Ludovic Courtès" <ludo@gnu.org>
To: Mikhail Tsykalov <tsymsh@gmail.com>
Cc: 41143@debbugs.gnu.org
Subject: [bug#41143] [PATCH 1/2] mapped-devices: Allow target to be list of strings
Date: Fri, 25 Sep 2020 18:20:51 +0200 [thread overview]
Message-ID: <87pn69j09o.fsf@gnu.org> (raw)
In-Reply-To: <cc872b95-370a-6247-cf44-64989e76bac6@gmail.com> (Mikhail Tsykalov's message of "Fri, 25 Sep 2020 16:36:11 +0300")
Hi,
Mikhail Tsykalov <tsymsh@gmail.com> 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.
WDYT?
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.
Thanks,
Ludo’.
next prev parent reply other threads:[~2020-09-25 16:26 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-09 1:12 [bug#41143] [PATCH 1/2] mapped-devices: Allow target to be list of strings tsmish
2020-05-09 1:22 ` [bug#41143] [PATCH 2/2] mapped-devices: Add 'lvm-device-mapping' tsmish
2020-09-09 20:48 ` Ludovic Courtès
2020-05-14 22:53 ` [bug#41143] Some clarification Mikhail Tsykalov
2020-05-15 1:17 ` [bug#41143] [PATCH] mapped-devices: Document lvm-mapping-device Mikhail Tsykalov
2020-06-06 13:40 ` [bug#41143] [PATCH 1/2] mapped-devices: Allow target to be list of strings Lars-Dominik Braun
2020-06-06 20:16 ` Mikhail Tsykalov
2020-06-07 6:48 ` Lars-Dominik Braun
2020-09-09 20:38 ` Ludovic Courtès
2020-09-24 16:09 ` Mikhail Tsykalov
2020-09-25 9:34 ` Ludovic Courtès
2020-09-25 13:36 ` Mikhail Tsykalov
2020-09-25 16:20 ` Ludovic Courtès [this message]
2020-10-01 22:48 ` [bug#41143] [PATCH v2 " Mikhail Tsykalov
2020-10-01 22:49 ` [bug#41143] [PATCH v2 2/2] mapped-devices: Add 'lvm-device-mapping' Mikhail Tsykalov
2020-10-04 10:34 ` Ludovic Courtès
2020-10-04 10:28 ` [bug#41143] [PATCH v2 1/2] mapped-devices: Allow target to be list of strings Ludovic Courtès
2020-11-05 9:48 ` Ludovic Courtès
2020-11-06 9:47 ` [bug#41143] [PATCH v3 " Mikhail Tsykalov
2020-11-06 9:47 ` [bug#41143] [PATCH v3 2/2] mapped-devices: Add 'lvm-device-mapping' Mikhail Tsykalov
2020-11-25 23:09 ` bug#41143: [PATCH v3 1/2] mapped-devices: Allow target to be list of strings Ludovic Courtès
2020-10-01 23:15 ` [bug#41143] [PATCH " Mikhail Tsykalov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pn69j09o.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=41143@debbugs.gnu.org \
--cc=tsymsh@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).