Re: Some question about Udev

Re: Some question about Udev

[Stanley Wang]

On Tue, 2003-08-05 at 00:10, Greg KH wrote:
> On Mon, Aug 04, 2003 at 09:20:15PM +0800, Stanley Wang wrote:
> > 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.
> 
> > 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?
> 
> udev will be called everytime /sbin/hotplug is 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?

> 
> > 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 tdb
> 
> It's a database package called "Tiny DataBase" from the samba authors.
> 
> Hope this helps,
> 
> greg k-h
-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Some question about Udev

[Kevin P. Fleming]

> On Tue, 2003-08-05 at 00:10, Greg KH wrote:
> 
>>>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?
>>
>>udev will be called everytime /sbin/hotplug is 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Some question about Udev

[Greg KH]

On Tue, Aug 05, 2003 at 08:55:00AM +0800, Stanley Wang wrote:
> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Some question about Udev

[Greg KH]

On Mon, Aug 04, 2003 at 06:25:34PM -0700, Kevin P. Fleming wrote:
> 
> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Some question about Udev

[Kevin P. Fleming]

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

Re: Some question about Udev

[Greg KH]

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

Re: Some question about Udev

[Kevin P. Fleming]

Greg KH wrote:

> 
> initramfs isn't freed from memory today :)

OK, well, that's different then..

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

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

> 
> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel