Am Donnerstag, 8. September 2011, 22:56:07 schrieb Alan McKinnon:
> On Thu, 08 Sep 2011 22:40:07 +0200
> 
> Michael Schreckenbauer <grim...@gmx.de> wrote:
> > 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
> 
> The / partition may contain, at a absolute minimum, only that software
> required to boot and start userspace. So you find mount, fsck and sh in
> there.
> <snip>

Thanks, Alan
http://en.wikipedia.org/wiki/Rhetorical_question

;)

Best,
Michael


Reply via email to