From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jookia <166291@gmail.com> Subject: Re: [PATCH] DISCUSSION: Jookia's Libreboot+LUKS+LVM FDE patch. Date: Wed, 16 Mar 2016 12:23:44 +1100 Message-ID: <20160316012344.GC5559@novena-choice-citizen.lan> References: <56e0c4cf.08d0190a.6a127.0d35@mx.google.com> <87r3fitiu6.fsf@gnu.org> <20160310211149.GA17073@novena-choice-citizen.lan> <871t7h140d.fsf@gnu.org> <20160311164236.GB28593@novena-choice-citizen.lan> <87r3fbpzwx.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:48135) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <166291@gmail.com>) id 1ag6jU-0007gE-Ov for guix-devel@gnu.org; Wed, 16 Mar 2016 04:23:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <166291@gmail.com>) id 1ag6jT-0004YX-OJ for guix-devel@gnu.org; Wed, 16 Mar 2016 04:23:08 -0400 Content-Disposition: inline In-Reply-To: <87r3fbpzwx.fsf@gnu.org> 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: Ludovic =?iso-8859-1?Q?Court=E8s?= Cc: guix-devel@gnu.org On Tue, Mar 15, 2016 at 03:40:46PM +0100, Ludovic Courtès wrote: > Would a ‘mapped-device’ type where both ‘source’ and ‘target’ are lists > adequately model Linux’s notion of mapped devices? I don't know, the problem is things like LVM create multiple mapped devices rather than just one. So it doesn't model the notion of mapped devices, but systems where multiple devices. > Keeping thing purely declarative, with high-level data structures such > as ‘file-system’ and ‘mapped-device’ is pretty nice IMO. It allows > users to easily inspect the config, map over the various bits, etc. This is true, but 'mapped-device' isn't a good abstraction I don't think since we're not often trying to map devices but instead use tools that automatically map them for us and take arguments, such as a key-file. In my patch you can see I have to make the mapped-device type field call a function to generate a type based on some LUKS-specific input. Perhaps mapped-device needs to be rethought? > Note that it already handles bind mounts and other pseudo file systems > (see (gnu system file-systems)). Basically, ‘file-system’ directly > corresponds to the ‘mount’ system call. It does, but I don't think it allows multiple devices in the dependency graph. > Hmm it seems to me that these are roughly to different ways to write the > same thing (with the 2nd one making dependencies explicit.) Oh, I typo'd a bit. In the second one device/swap-device/lvm-device/luks-device should all just be 'device', since it's unified. > I’m not sure there’s an intermediate representation that file systems, > swap devices, LVM devices, etc. could all be “compiled” to. I feel that > we should stick to the abstractions of the Linux kernel, where device > mapping is entirely different from file systems, and so on. I don't think this is compiling to a representation of the devices themselves, but more a dependency graph. But yeah, you're probably right on that. I thought about it a bit above, but perhaps mapped-device needs to be expanded from just 'type' to things like lvm-mapped-device where we can have some more control. Mirroring this, most mapped devices aren't directly called with something like 'mount', but instead userspace utilities. > However, we must definitely unify device naming (the /dev vs. UUID > vs. label thing.) Yes, definitely. > What? :-) I mentioned it above, but mapped-device doesn't support per-type arguments. Like specifying a key-file for LUKS or volume group for LVM. mapped-device also doesn't allow specifying output devices so we can't really handle dependencies between them properly either. > Thanks for your insightful comments! Yours too, I hope we figure out something that solves both our issues. :) > Ludo’. Jookia.