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

[Kay Sievers]

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.

> 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.

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.

Kay