From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [PATCH] vm: Have qemu-image generate derivations instead. Date: Tue, 29 Mar 2016 21:46:14 +0200 Message-ID: <87h9fphxtl.fsf@gnu.org> References: <56c321ad.e4f9420a.ee59b.4aa7@mx.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:51357) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akzap-00016D-4C for guix-devel@gnu.org; Tue, 29 Mar 2016 15:46:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akzak-0007j6-0r for guix-devel@gnu.org; Tue, 29 Mar 2016 15:46:23 -0400 In-Reply-To: <56c321ad.e4f9420a.ee59b.4aa7@mx.google.com> (Jookia's message of "Thu, 11 Feb 2016 11:41:53 +0000") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Jookia <166291@gmail.com> Cc: guix-devel@gnu.org Jookia <166291@gmail.com> skribis: > This small refactor should simplify some duplicated effort across functio= ns and > allow smarter qemu-image to do smarter things based on the operating syst= em > configuration rather than having each function that uses qemu-image pass > selective parameters whenever new information is needed. Damn, it=E2=80=99s been more than a month, please accept my apologies! Overall this sounds like a good idea. However=E2=80=A6 > * gnu/system/vm.scm (qemu-image): Replace os-derivation, grub-configurati= on and > inputs parameters with os-configuration, base-inputs and extra-inputs. > (qemu-image): Based on base-inputs, generate grub.cfg and os-drv. > (system-disk-image, system-qemu-image, system-qemu-image/shared-store): > Pass in the operating system configuration and base-inputs to qemu-image > instead of derivations. One of the reasons =E2=80=98os-drv=E2=80=99 and =E2=80=98grub.cfg=E2=80=99 = are passed around is that recomputing them is relatively costly. There=E2=80=99s a solution to that in 4c2ade20c65e94c41dc8c65db73dd128343a0= ad5 (in =E2=80=98wip-build-systems-gexp=E2=80=99; it memoizes =E2=80=98operatin= g-system-derivation=E2=80=99 and others), so we could almost consider it solved. Nevertheless it=E2=80=99d be nice to make sure performance remains reasonab= le even in the absence of the above commit. > + (base-inputs (list 'grub.cfg 'system)) [...] > + (mlet* %store-monad ((os-drv (operating-system-derivation os-configu= ration)) > + (grub.cfg (operating-system-grub.cfg os-configura= tion)) > + (inputs -> (append > + (if (member 'grub.cfg base-inputs) > + `(("grub.cfg" ,grub.cfg)) '()) > + (if (member 'system base-inputs) > + `(("system" ,os-drv)) '()) Use of =E2=80=9Cmagic=E2=80=9D values like 'grub.cfg here is undesirable IM= O, because it introduces singularities in the API, and generally makes the interface non-obvious. So I think I=E2=80=99d leave it up to the caller to pass #:inputs `(("grub.cfg" ,grub.cfg))=20 Same for "system". All in all, I sympathize with the desire to avoid passing OS-DRV and GRUB.CFG around, but I=E2=80=99m not convinced that this approach can impro= ve the situation. WDYT? Thank you! Ludo=E2=80=99.