From: Jookia <166291@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: [PATCH] DISCUSSION: Jookia's Libreboot+LUKS+LVM FDE patch.
Date: Wed, 16 Mar 2016 12:23:44 +1100 [thread overview]
Message-ID: <20160316012344.GC5559@novena-choice-citizen.lan> (raw)
In-Reply-To: <87r3fbpzwx.fsf@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.
next prev parent reply other threads:[~2016-03-16 8:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-10 0:36 [PATCH] DISCUSSION: Jookia's Libreboot+LUKS+LVM FDE patch Jookia
2016-03-10 7:48 ` Taylan Ulrich Bayırlı/Kammer
2016-03-10 12:36 ` Jookia
2016-03-10 16:10 ` Ludovic Courtès
2016-03-10 21:11 ` Jookia
2016-03-11 14:30 ` Ludovic Courtès
2016-03-11 16:42 ` Jookia
2016-03-15 14:40 ` Ludovic Courtès
2016-03-16 1:23 ` Jookia [this message]
2016-03-14 21:40 ` Jean Louis
-- strict thread matches above, loose matches on Subject: below --
2016-03-10 0:36 Jookia
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160316012344.GC5559@novena-choice-citizen.lan \
--to=166291@gmail.com \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).