Am Donnerstag, 8. September 2011, 22:05:36 schrieb Alan McKinnon: > On Thu, 08 Sep 2011 19:11:04 +0200 > > Michael Schreckenbauer <grim...@gmx.de> wrote: > > > Then design the correct solution and implement it. If it's > > > technically sound, it will prevail. I think it's a rather > > > complicated problem with a non trivial solution, but the code is > > > there if you feel like give it a try. > > > > Where did I write, that I am in the position to write such a beast? > > I only take the freedom to name this a design flaw in udev. > > It needs things from userspace, which are not yet available at the > > point it requests them. An initramsfs is a workaround for this, not a > > proper fix. > > If that is the argument from the udev devs you just quoted, then I do > not understand it at all.
It's my understanding, that this is their point. > Why can there not be a restriction that udev may only run code in the > traditional / space (i.e. it will not attempt to run code in the /usr > or /home spaces)? Yes. I really wonder, why we have /bin, /sbin and /lib > Device nodes are a root function; root is the only user that should > dictate how device nodes are created; root is the only user that can > normally write to / and thereby create udev's rules and rulesets. > > In what valid way does access to /usr become something that udev may be > required to support? As udev is able to run arbitrary scripts, there *might* be some code, that requires something from /usr/*. So they want this beast be mounted, before udev starts doing it's job. > Not arguing with *you* here Michael, just wondering about the validity > of the position you quoted Understood :) Regards, Michael
