Re: Some question about Udev

["Kevin P. Fleming" <kpfleming@cox.net>]

Greg KH wrote:
> On Mon, Aug 04, 2003 at 06:25:34PM -0700, Kevin P. Fleming wrote:
> 
> Well, the "state" will still be running in memory, as udev will be
> becoming a daemon soon, so that will not be a big problem.  As for the
> pivot issue, I'm still trying to work that out...

Interesting... so you see the udev binary itself becoming a "client" 
that sends commands and get responses back? That could work, although 
if there is a daemon process running that was started using the udev 
binary in the initramfs, that could cause problems with the initramfs 
being freed from memory (although I think it would only make the udev 
binary itself stick around, since the initramfs is _not_ an initrd and 
doesn't have to be freed all-or-nothing).

> 
> I'm thinking that udev will just create a ramfs partition for /dev and
> then after pivot root happens, just re-mount that partition on top of
> the new /dev whereby things just keep working.  Haven't really tried
> that yet, as we still need some more kernel tweaks to get there...
> 

Well, this is one case where having a single-instance memory-based 
filesystem (ala devfs, but without all the cruft) would be extremely 
helpful. I don't know how (today) udev could remount a ramfs 
filesystem in a different location, because there's no way to refer to 
that existing filesystem.

I'd suggest possibly talking to Adam Richter about leveraging his 
"small devfs" work... he had a ramfs-based single-instance filesystem 
built, which could have all the device node magic removed and just be 
a simple filesystem for udev to use. This leads me to another point: 
I'm not sure I would be comfortable with udev keeping its state only 
in RAM. If some bug in udev should manifest itself as a process crash, 
there'd be no way to recover that state. Also, it would not be 
possible to implement an upgrade to udev without restarting the 
system, although granted I don't see that as a big deal.

With a single-instance filesystem being used, udev could actually used 
tdb to store the state in magic files in the filesystem, thereby 
solving these problems.



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel