[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 03:00:14PM +0200, Kay Sievers wrote:
> On Wed, Oct 24, 2012 at 2:23 PM, Zbigniew Jędrzejewski-Szmek
> <zbyszek at in.waw.pl> wrote:
> > 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
> >> >
> >> > 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.
> 
> I'll check that when it's merged; in 3.8, I guess.
> 
> > This will likely be
> > a very rarely used fs
> 
> We will likely end up using it ourselves from PID1 to extract boot
> loader performance data, just like we do the initrd and other timing
> data there. So an automount might not give us any real advantage in
> the end.
OK.

> > so if the loading time is actually measureable,
> > than automount probably makes sense.
> 
> On EFI systems it will not really be measurable, I guess. The mount is
> almost free, because the superblock is in the kernel anyway, very much
> like like proc, sysfs, devtmpfs.
> 
> For non-EFI systems, it might cause a "useless" kernel-initiated
> modprobe, which we probably want to avoid by some condition.
> 
> >> 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.
> 
> Right, but maybe we can key-off some other condition, which indicates
> an EFI bootup, so we can avoid trying to mount things on systems where
> it can't be there.
> 
> Looking at if from a distance:
> I guess the kernel should just start mounting its "crap" on its own,
> instead of relying on userspace to know anything about this
> ever-changing stuff. This filesytem is just a directory in /sys,
> nothing else for userspace to know about it.
Actually, in a container, it might make sense to not mount
/sys/firmware/efi/efivars, since it opens an avenue to modify kernel
state.

> Requiring to patch userspace to mirror the fashion-of-the-month kernel
> setup really does not scale in the longer run. Userspace really does
> not want to know all these things. It has the right to, and wants to
> be "stupid" here, and does not really want to fiddle around in such
> kernel-internals.
> 
> It might be time to think all this through, it seems very much like an
> entirely needless loop to jump through userspace here.

Zbyszek