[systemd-devel] [PATCH] Add syste-firmware-efi-efivars.mount for support automount EFI variable filesystem

[Zbigniew Jędrzejewski-Szmek]

On Wed, Oct 24, 2012 at 02:17:39PM +0200, Kay Sievers wrote:
> On Wed, Oct 24, 2012 at 2:12 PM, Zbigniew Jędrzejewski-Szmek
> <zbyszek at in.waw.pl> 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.
Probably should be measured by someone with UEFI. This will likely be
a very rarely used fs, so if the loading time is actually measureable,
than automount probably makes sense.

> 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.
Yeah, the ConditionPathExists would have to be dropped.

Zbyszek