Re: Some question about Udev

[Greg KH <greg@kroah.com>]

On Tue, Aug 05, 2003 at 11:19:57AM -0700, Kevin P. Fleming wrote:
> 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?

No, no messages back.  Just a one-way pipe, from hotplug event to queued
up udev message.  We have to do that to be able to keep track of
out-of-order events.

> 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).

initramfs isn't freed from memory today :)

> >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.

Yeah, I've thought about that.  Hacking up a udevfs would be a piece of
cake due to the libfs code in the kernel if it comes to that.  Just a
ramfs image that allows multiple mounts.

> 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.

Already wrote such a thing a long time ago, look at pcihpfs in 2.4 and
usbfs in 2.6 :)

> 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.

It's a piece of cake to rebuild a udev database, as we can just walk the
sysfs tree.  So any "errors" or restarts is easy to handle.

> 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.

Ick, I'll just stick with tdb using "normal" files to store such a
state.  On restart, just rebuild the database.  Actually, using tdb's
"ram database" option will be the way to go.

thanks,

greg k-h


-------------------------------------------------------
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