Some question about Udev
Quoted 6 lines · Greg KH
Quoted 2 lines · Stanley Wang
Hi Greg,
I have some question about Udev, please help me :)Try asking these on the linux-hotplug-devel mailing list next time, so that others can see the answers for future searches.
Thanks a lot! I forget to CC linux-hotplug-devel.
Quoted 9 lines
Quoted 8 lines
1. How does Udev deal with the devices that can't be hot plugged ? such as IDE disk, sound card.
If we want to use Udev to replace /dev, we must also manager these devices. But these devices are probed at system boot time and will not trigger the hotplug script, how could we know the existence of them ? Could we call the Udev in the init process and go through /sys to create all devices' files?
Quoted 4 lines
udev will be called everytime
/sbin/hotplugis called, and that is called every time we find a device during the boot process. I'll put udev into the initramfs image so it too will be present during that time. This way we will not miss any events.
My question: Could we boot the kernel by using udev and a empty /dev directory?
Quoted 16 lines
Quoted 10 lines
2. When you talked about namedev in your slices(page 11), you mentioned "tdb". What's it?
Quote from your slices:NAMEDEV
[snip]*able to be queried to determine current devices
*uses tdbIt's a database package called "Tiny DataBase" from the samba authors.
Hope this helps,
greg k-h
Signature · 16 lines
Opinions expressed are those of the author and do not represent Intel
Corporation
"gpg --recv-keys --keyserver wwwkeys.pgp.net E1390A7F"
{E1390A7F:3AD1 1B0C 2019 E183 0CFF 55E8 369A 8B75 E139 0A7F}
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-develQuoted 10 lines · Greg KH
Quoted 9 lines
Quoted 8 lines
1. How does Udev deal with the devices that can't be hot plugged ? such as IDE disk, sound card.
If we want to use Udev to replace /dev, we must also manager these devices. But these devices are probed at system boot time and will not trigger the hotplug script, how could we know the existence of them ? Could we call the Udev in the init process and go through /sys to create all devices' files?
Quoted 5 lines
Quoted 4 lines
udev will be called everytime
/sbin/hotplugis called, and that is called every time we find a device during the boot process. I'll put udev into the initramfs image so it too will be present during that time. This way we will not miss any events.
Greg, how you do foresee the udev database (the tdb file(s)) and the /dev nodes it has created persisting across the mounting of the real root filesystem? Even if the root filesystem is mounted elsewhere and then pivoted onto /, that still means that udev's "state" is going to be effectively relocated.
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 2 lines · Stanley Wang
My question: Could we boot the kernel by using udev and a empty /dev directory?
That is the end goal, yes. We are not there yet today due to some missing kernel patches (that are in my tree still), and some initramfs tweaking.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines · Kevin P. Fleming
Greg, how you do foresee the udev database (the tdb file(s)) and the /dev nodes it has created persisting across the mounting of the real root filesystem? Even if the root filesystem is mounted elsewhere and then pivoted onto /, that still means that udev's "state" is going to be effectively relocated.
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...
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...
Any help in this area would be appreciated.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 5 lines · Greg KH
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).
Quoted 6 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 9 lines · Kevin P. Fleming
Quoted 5 lines · Greg KH
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.
Quoted 6 lines
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 :)
Quoted 11 lines
Quoted 5 lines
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.
Quoted 4 lines
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 :)
Quoted 6 lines
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.
Quoted 3 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 2 lines · Greg KH
initramfs isn't freed from memory today :)
OK, well, that's different then..
Quoted 4 lines
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.
Here's another thought (somewhat off-topic for this list): I have been considering implementing a sysfs "class" for filesystems. If something like that existed, the tmpfs (or ramfs) filesystem "driver" could expose information about each existing tmpfs instance, including some sort of cookie. With the addition of a new mount option for the tmpfs filesystem, it would be possible to specify a remount of that existing tmpfs instance by passing in the cookie for the existing instance. Another option would be to make this cookie appear in /proc/mounts, which would certainly be quicker to implement than a new sysfs class. Thoughts?
Quoted 3 lines
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.
Hmmm... I guess I was thinking about things like udev tracking hotplug event sequence numbers and such, needing to remember more than just "what exists in sysfs right now". I may have been reading too much into the situation though.
Quoted 4 lines
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.
Well, by "magic" I just meant normal files that the user wouldn't see.
Something like /dev/.udev_state.tdb that could just sit around in
case another udev instance needed it. Sorry for the poor terminology choice there.
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel