Hello Lennart
Sorry, I missed that mail...
Beside referring to the bugzilla description I could simplify
the usecase to this:
- prepare e.g. /home on luks, use 2 keys: passphrase and key-in-file
- put the key file on usb stick
- start machine without usb stick inserted
- it won't ask for passphrase and so won't boot
With the bugfix (and related /fstab x-timeout entry for ubs stick) it
will correctly ask for the passphrase when usb stick is not in.
Actually I'm out of time and cannot spent more time on this. I could
change the code as suggested but cannot test it then and I
don't want to send untested patch.
The bug in systemd dependency is already localized and the bugfix
solution code is provided, feel free to use it, re-implement/change/drop
as you wish.
Regards
Przemek
On 07/03/2014 01:36 PM, Lennart Poettering wrote:
> On Sun, 25.05.14 12:39, Przemek Rudy (pru...@o2.pl) wrote:
>
>> -Set *manager_get_units_requiring_mounts_for(Manager *m, const char *path) {
>> +Set *manager_get_units_need_mounts_for(Manager *m, const char *path,
>> bool strong) {
>
> Please don't invent new bools halfway. Please always use the same logic
> here to discern the two kinds, i.e. the dep type enum.
>
>> * them. It's a hashmap with a path string as key and a Set as
>> - * value where Unit objects are contained. */
>> - Hashmap *units_requiring_mounts_for;
>> + * value where Unit objects are contained.
>> + * [0] - map of required (strong) paths
>> + * [1] - map of wanted (weak) paths */
>> + Hashmap *units_need_mounts_for[2];
>
> Please use two normal variables for this. Two isn't that many that you'd
> need to defer to an array for this. Also, an array where we use
> arbitrary numeric indexes for reference two different concepts is not
> OK. If we do this, then we must have an enum to reference this. Also,
> introducing a new numbering scheme, where we already have the dep type
> as enum...
>
> Generally, I still don't really feel that the usecase for this is strong
> enough. Can you make a strong concise case why we want this? I am not
> totally opposed, but I want to know why I merge this...
>
> Lennart
>
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
