From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Kevin P. Fleming" Date: Tue, 05 Aug 2003 18:19:57 +0000 Subject: Re: Some question about Udev Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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