On Wed, Oct 24, 2012 at 3:09 PM, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > 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. /sys (and all below) should be read-only inside a container anyway, so it would only be readable, which might be bad enough, but not that much different from the rest of /sys. "Make sure to pre-mount /sys, and /proc, /sys/fs/selinux before invoking systemd, and mount /proc/sys and the entirety of /sys and /sys/fs/selinux read-only in order to avoid that the container can alter the host kernel's configuration settings." http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface Also, in a container we mount 'sysfs' explicitly, not with a bind-mount from the host, so this would not be inherited anyway, I guess. 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
