[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.