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. 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)? 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? Not arguing with *you* here Michael, just wondering about the validity of the position you quoted -- Alan McKinnnon alan.mckin...@gmail.com
