On Sat, Oct 15, 2011 at 2:53 AM, Neil Bothwick <n...@digimed.co.uk> wrote: > On Sat, 15 Oct 2011 00:34:10 -0700, Canek Peláez Valdés wrote: > >> /var != /var/run >> /var != /var/lock >> >> /var/run is going in /run, but /var/run (by definition) only contains >> things like PID files and runtime sockets. In the same vein, /var/lock >> also is going into /run/lock. I have acknowledged this from the very >> beginning, and I have been pointing out that implying that because >> those two (really small and bounded) directories of /var are going >> into /run and /run/lock, > > Putting the contents of /var/run and /var/lock on the root filesystem > makes sense. > >> Nobody has even proposed that /var should go into the same partition >> as /. *Nobody*, and the simplest proof of that is that nobody has >> produced a single proof to the contrary. Not a single email, blog >> post, or wiki entry from any system developer even mentions the >> possibility of requiring /var to be in the same partition as /. > > The stated reason for requiring /usr on / is that udev can run > *arbitrary* scripts and commands. If they are arbitrary, they could > require access to anywhere, including /var or /home. That's the problem > with this approach. Instead of saying "it can run stuff from anywhere, so > anywhere must be mounted before udev is run" the fact that it is trying > to run these arbitrary commands before filesystems are mounted should be > addressed.
With an initramfs you can have everything mounted by udev execution time. But forget about that. It's arbitrary (basically) on executables and libraries. If an script needs something more (from /var, lets say), then the rule should be written in such a way that it can be called after that directory is mounted. If you try to put the same restriction with *executables* (not data, like in the ALSA case), then you need to start moving every executable to /, because that's the only way to guarantee that it would be available aearly on boot time (if you don't use an initramfs and have /usr separated). That sucks. /bin and /lib were the original hack, for this very reason: some executables were needed early at boot time, and they put them there so they were available. The initramfs solves this problem; at some point, /bin /lib and /sbin will no longer be necessary. So yeah, the udev rules can execute arbitrary code, but the should not run stupid code. There is a difference. >> Whoever says that /var will be required to be on the same partition as >> / is either wildly speculating, or spreading FUD. > > It's not wild speculation, it is logical extrapolation of the current > approach. You don't have enough data to extrapolate. >> It basically removes the need for a "pesky init* thingy", although for >> the life of me I cannot understand why someone will not see the >> technical advantages of actually using an initramfs. > > We understand its advantages in some circumstances, but I cannot > understand why someone will not see the technical disadvantages of > actually using an initramfs. Care to explain? Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
