From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Date: Wed, 06 Aug 2003 07:23:34 +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 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