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.
