On Wed, Oct 24, 2012 at 2:12 PM, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > On Wed, Oct 24, 2012 at 06:42:02PM +0800, Lee, Chun-Yi wrote: >> Add units/sys-firmware-efi-efivars.mount rule for support automount EFI variable filesystem >> --- > Hi, > > in systemd parlance, automount means autofs mount, but to have that, a > second .automount unit is needed. Please have a look at > http://cgit.freedesktop.org/systemd/systemd/tree/units/proc-sys-fs-binfmt_misc.automount > vs > http://cgit.freedesktop.org/systemd/systemd/tree/units/proc-sys-fs-binfmt_misc.mount . > Now the question is whether the loading of the fs is slow enough to > matter, ie. if it is actually beneficial to use automount instead of > mounting directly. Since the fs can be compiled as a module, than it > probably is. > > Also, would be nice to add a Documentation= line like in > proc-sys-fs-binfmt_misc.automount. It might all not be worth it, and we might just add it to the "unconditionally mounted" list in the compiled-in code (marked with allowed-to-fail). It seems like the better option than having a mount unit, and a module-load force option. The current mount unit would never trigger for modules, because the path will not exist. An internal API mount will cause a trransparent kernel-forked modprobe with the mount() syscall. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
