From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 25 09:36:21 2020 Received: (at 41143) by debbugs.gnu.org; 25 Sep 2020 13:36:21 +0000 Received: from localhost ([127.0.0.1]:43056 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kLntd-0000eN-9M for submit@debbugs.gnu.org; Fri, 25 Sep 2020 09:36:21 -0400 Received: from mail-lj1-f195.google.com ([209.85.208.195]:37012) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kLntb-0000dt-0X for 41143@debbugs.gnu.org; Fri, 25 Sep 2020 09:36:19 -0400 Received: by mail-lj1-f195.google.com with SMTP id n25so2505391ljj.4 for <41143@debbugs.gnu.org>; Fri, 25 Sep 2020 06:36:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=aOCfoT3vgHE383oj6lE6jqqhjXe49/xiwTf5JyYIqZs=; b=Ht+VMvndcnAkAcDpa4dLsAr3Fr+GHVyCsKHYUa+Qk/OwtYh+UuA89gul00xjdxsgjd k4vL9rN344Tvhneu0zMwezYZivRySOLeqDRdnNMTDg/FIZYgfFkSWu56dznu1DVkucII vyLqmQitu1dx68oyMpraqMOXQdAcVmXv97sWk7jBs8q/+MgskOXWNx6BkFQFQYZif0wN v+X8EZp0lKHk9Vkd8nf8LmwBD/1y2faX1qxQcbDtLi4c+r0wQCJSw0GIe5YyvoxwDlvO /1HlaBPdD46FojBzJeYSRMGe6Z8p7r31Re6mqG3gPWoRcmn8O1GkKhwkohfhm2IWsg/y TmZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=aOCfoT3vgHE383oj6lE6jqqhjXe49/xiwTf5JyYIqZs=; b=OvWV0h507PsPMl76CQrlElh7f/3YYYuuM17+gax4zp6hM/IAaTtKVKQeFJbAeDgXi5 k68c4A6KSobTbVkau012kyEeRpWN0eBNBJ4ib2z8bR6hJn6/NtmJUVOwZ1g9vkJYoByc PeuKHbIq4E9O824eW8961I3KhfezwUDL1VbnKFgd+d1RRacReJYknPwjaPAA1C+oCUpO RZRXVCYN/QrBx15fFGpZgLe9F503ELw1MP5BCHGmSrmqHTpjCBYIAQBZ90ZNB5owtsXO trnCnt1rkTWEx2ISSLZyi7cm5Y4uPt19SRrbpXIGaoShcgqEfo0MTiVWg21HGqBsvfKs Q0dA== X-Gm-Message-State: AOAM5317JvFCi8Y0MOX9MQ3UKhDf6O+IGIIt7P810i4F/sUA7cswcB4+ Ui/3vIdc7zZ4TzrAEMFhozfwo8oG4QtPug== X-Google-Smtp-Source: ABdhPJzVEq3PyB7c0VBsjqIlsabrzPPJIEk+JVB5mEuW4UHVrsaAqYMgQu7ibs3p+wRR2SY3yMkOUg== X-Received: by 2002:a2e:8645:: with SMTP id i5mr1296027ljj.209.1601040972266; Fri, 25 Sep 2020 06:36:12 -0700 (PDT) Received: from [192.168.0.143] ([88.201.200.148]) by smtp.gmail.com with ESMTPSA id y26sm2255271lfy.163.2020.09.25.06.36.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Sep 2020 06:36:11 -0700 (PDT) Subject: Re: [bug#41143] [PATCH 1/2] mapped-devices: Allow target to be list of strings To: =?UTF-8?Q?Ludovic_Court=c3=a8s?= References: <874ko6n0s5.fsf@gnu.org> <9ac560cc-8660-f034-c0d8-536b68d20f68@gmail.com> <87r1qq2o92.fsf@gnu.org> From: Mikhail Tsykalov Message-ID: Date: Fri, 25 Sep 2020 16:36:11 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Icedove/68.12.0 MIME-Version: 1.0 In-Reply-To: <87r1qq2o92.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Score: -0.2 (/) X-Debbugs-Envelope-To: 41143 Cc: 41143@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.2 (-) Hi, Ludovic On 25.09.2020 12:34, Ludovic Courtès wrote: > Hi Mikhail, > > Mikhail Tsykalov skribis: > >> On 09.09.2020 23:38, Ludovic Courtès wrote: >>>> diff --git a/gnu/services/base.scm b/gnu/services/base.scm >>>> index 0c154d1c4e..3d09e8220c 100644 >>>> --- a/gnu/services/base.scm >>>> +++ b/gnu/services/base.scm >>>> @@ -408,7 +408,10 @@ FILE-SYSTEM." >>>> (define (mapped-device->shepherd-service-name md) >>>> "Return the symbol that denotes the shepherd service of MD, a >>>> ." >>>> (symbol-append 'device-mapping- >>>> - (string->symbol (mapped-device-target md)))) >>>> + (string->symbol (string-join >>>> + (let ((t (mapped-device-target md))) >>>> + (if (list? t) t (list t))) >>>> + "-")))) >>> To avoid duplicating the (if (list? t) …) everywhere, I propose instead >>> the following approach: >>> >>> 1. Rename ‘target’ to ‘targets’ (plural) and likewise for the >>> accessor, and agree that it always contains a list; >>> >>> 2. Rename ‘mapped-device’ to ‘%mapped-device’ and add a >>> ‘mapped-device’ backward-compatibility macro that allows for a >>> ‘target’ (singular) field and automatically turns its value into a >>> list. See the ‘origin’ macro in (guix packages) for an example of >>> how to do that (that macro allows users to specify ‘sha256’ instead >>> of ‘hash’). >>> >>> 3. Add a deprecated ‘mapped-device-target’ (singular) that returns the >>> first element returned by ‘mapped-device-targets’. >> 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. To be fair, after thinking about it for a bit, I think that this issue can be solved by renaming mapped-device-kind and providing compatibility macros similar to %mapped-device. Still question remains about what should we do if a list gets passed to a kind that doesn't expect it, but I think we can just raise an error in macro if that's the case. Does this sound fine to you? Thanks, Mikhail