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@xxxxxxxxx> 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@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 > >> > > >> > 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 -- 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
