From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id AN9yDZvybV8XYAAA0tVLHw (envelope-from ) for ; Fri, 25 Sep 2020 13:37:31 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id UKpgCZvybV9KRQAA1q6Kng (envelope-from ) for ; Fri, 25 Sep 2020 13:37:31 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 95764940430 for ; Fri, 25 Sep 2020 13:37:30 +0000 (UTC) Received: from localhost ([::1]:40054 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kLnuj-0000RF-GV for larch@yhetil.org; Fri, 25 Sep 2020 09:37:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59744) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kLnuI-0000MI-KV for guix-patches@gnu.org; Fri, 25 Sep 2020 09:37:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:59744) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kLnuI-0007Tf-Ac for guix-patches@gnu.org; Fri, 25 Sep 2020 09:37:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kLnuI-0000fV-6z for guix-patches@gnu.org; Fri, 25 Sep 2020 09:37:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#41143] [PATCH 1/2] mapped-devices: Allow target to be list of strings Resent-From: Mikhail Tsykalov Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Fri, 25 Sep 2020 13:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41143 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 41143@debbugs.gnu.org Received: via spool by 41143-submit@debbugs.gnu.org id=B41143.16010409812508 (code B ref 41143); Fri, 25 Sep 2020 13:37:02 +0000 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) 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Spam-Score: -1.2 (-) X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=fail (rsa verify failed) header.d=gmail.com header.s=20161025 header.b=Ht+VMvnd; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Spam-Score: 0.09 X-TUID: plxoXgzXJB+/ 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