On Fri, 29.08.14 15:28, Jan Janssen ([email protected]) wrote: heya,
sorry for the late review! Hmm, not generally opposed to allowing this to be configured on the kernel cmdline, but this is so awfully asymmetric now. luks.uuid= so far accepts a single UUID, but may be specified multiple times luks.options= accepts a UUID, followed by a "=", followed by the options for that specific volume, may be specified multiple times luks.key= accepts a single key file, but may be specified a single time only Now you want to extend: luks.uuid= would then accept a UUID, followed by a ":", followed by the dm name for the specific volume Correct? I really don't like that. It's already awfull chaotic, and now it becomes even worse... Maybe, to stay uniform, introduce luks.name=$UUID=$NAME or so? this would map the luks.options= syntax at least (not that that was a particularly pretty syntax, but well...). In fact, we should probably extend luks.key= to also accept a syntax for this: luks.key=$UUID=$KEY or so... Any maybe if luks.options= does not start with $UUID= it should just be considered the default options for all entries. Does that make any sense? For now, could you rework your patch to follow this scheme? (I mean, only do the luks.name= syntax the way I propose above, not the other stuff). I'd prefer if we'd push all luks partitions that are configured into a Hashmap btw, keyed by the uuid, and with a new struct as value, where we can fill things in. Constantly iterating through the various arrays over and over again is neither pretty nor efficient. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
