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