guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] DISCUSSION: Jookia's Libreboot+LUKS+LVM FDE patch.


From: Jookia
Subject: Re: [PATCH] DISCUSSION: Jookia's Libreboot+LUKS+LVM FDE patch.
Date: Wed, 16 Mar 2016 12:23:44 +1100
User-agent: Mutt/1.5.24 (2015-08-30)

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]