Messages in this thread | | | From | (Eric W. Biederman) | Date | Fri, 18 Sep 2009 07:42:08 -0700 | Subject | Re: [PATCH] Remove broken by design and by implementation devtmpfs maintenance disaster |
| |
Arjan van de Ven <arjan@infradead.org> writes:
> On Fri, 18 Sep 2009 06:54:39 -0700 > ebiederm@xmission.com (Eric W. Biederman) wrote: > >> >> > I don't understand. Udev applies the final policy including >> > permissions/ownership, just as before. There is no differrence. It's >> > just that you can bring up a box without complex userspace to >> > bootstrap /dev. And that's a big win on its own. >> >> udev is too complex to use? That sounds like a userspace bug. >> >> This I guess is where I am baffled. The argument for devtmpfs >> always seem to boil down to: udev sucks let's write some kernel >> code instead. >> >> I have been trying to ask for a long time why we can't just fix >> udev to not suck. >> >> > And things like >> > "modprobe loop; losetup /dev/loop0" will just work, which it doesn't >> > with todays async udev. Again, please make yourself familiar how >> > things work, and what the problems are. >> >> I guess I don't understand why >> modprobe loop; losetup /dev/loop0 is an interesting case. >> When you can just as easily do: >> modprobe loop; udevadm settle; losetup /dev/loop0. > > frankly, modprobe should call the settle. > And not just this one, but we can use this to settle other things as > well... and then it can get an --async command line option for the > cases where you know you don't want to synchronize.
I think this would be a bit of a pain when I modprobe a network driver and the udev scripts trigger a blocking dhcp on the device.
If this is a major pain point in initscripts I can see how it would make sense.
Eric
| |