Re: devfs to be obsloted by udev?

[Ed Sweetman <ed.sweetman@wmich.edu>]

Greg KH wrote:
> On Tue, Sep 02, 2003 at 10:09:48AM -0400, Ed Sweetman wrote:
> 
>>It appears that devfs is to be replaced by the use of udev in the not so 
>>distant future.
> 
> 
> Possibly.  There are some things that udev can not do that only devfs in
> the kernel can do.  For those who need those things, devfs will be
> required.
> 
> I'm just offering people a choice :)
> 
> 
>>I'm not sure how it's supposed to replace a static /dev situaton
>>seeing as how it is a userspace daemon.  Is it not supposed to replace
>>/dev even when it's completed?
> 
> 
> Yes.
> 
> Think of a userspace daemon using mknod and rm to manage device nodes
> dynamically.
> 
> 
>>I dont see the real benefit in having two directories that basically
>>give the same info.
> 
> 
> What "two directories"?  udev can handle /dev.  What other directory are
> you talking about?

in your readme you  use the example of making the device root for udev 
/udev ... I thought that was the official suggestion since udev couldn't 
be loaded immediately at kernel boot.


> 
>>Right now we have something like that with proc and sysfs although not
>>everything in proc makes sense to be in sysfs and both are virtual
>>fs's where as /dev is a static fs on the disk that takes up space and
>>inodes and includes way too many files that a system may not use.
> 
> 
> Then delete your /dev and use udev to manage it.
> 
> Well, don't do that today, we aren't quite yet there :)
> 
> 
>>If udev is to take over the job of devfs, how will modules and drivers
>>work that require device files to be present in order to work since
>>undoubtedly the udev daemon will have to wait until the kernel is done
>>booting before being run.
> 
> 
> udev can run out of initramfs which is uncompressed before any busses
> are probed.
> 
> For more details, please read my OLS 2003 paper about udev.

Will do.  The initramfs is an interesting method, i'll have to check 
that out too.


> 
>>I'm just not following how it is going to replace devfs and thus why 
>>devfs is being abandoned as mentioned in akpm's patchset. Or as it 
>>seems, already has been abandoned.
> 
> 
> The devfs code base has been abandoned by its original
> author/maintainer.  udev has nothing to do with that.
> 
> Hope this helps,
> 
> greg k-h
> 

i didn't think udev was responsible for the lack of development, I 
assumed that was due to the lack of devfs adoption in the main stream.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Greg KH wrote:
> On Tue, Sep 02, 2003 at 10:09:48AM -0400, Ed Sweetman wrote:
> 
>>It appears that devfs is to be replaced by the use of udev in the not so 
>>distant future.
> 
> 
> Possibly.  There are some things that udev can not do that only devfs in
> the kernel can do.  For those who need those things, devfs will be
> required.
> 
> I'm just offering people a choice :)
> 
> 
>>I'm not sure how it's supposed to replace a static /dev situaton
>>seeing as how it is a userspace daemon.  Is it not supposed to replace
>>/dev even when it's completed?
> 
> 
> Yes.
> 
> Think of a userspace daemon using mknod and rm to manage device nodes
> dynamically.
> 
> 
>>I dont see the real benefit in having two directories that basically
>>give the same info.
> 
> 
> What "two directories"?  udev can handle /dev.  What other directory are
> you talking about?

in your readme you  use the example of making the device root for udev 
/udev ... I thought that was the official suggestion since udev couldn't 
be loaded immediately at kernel boot.


> 
>>Right now we have something like that with proc and sysfs although not
>>everything in proc makes sense to be in sysfs and both are virtual
>>fs's where as /dev is a static fs on the disk that takes up space and
>>inodes and includes way too many files that a system may not use.
> 
> 
> Then delete your /dev and use udev to manage it.
> 
> Well, don't do that today, we aren't quite yet there :)
> 
> 
>>If udev is to take over the job of devfs, how will modules and drivers
>>work that require device files to be present in order to work since
>>undoubtedly the udev daemon will have to wait until the kernel is done
>>booting before being run.
> 
> 
> udev can run out of initramfs which is uncompressed before any busses
> are probed.
> 
> For more details, please read my OLS 2003 paper about udev.

Will do.  The initramfs is an interesting method, i'll have to check 
that out too.


> 
>>I'm just not following how it is going to replace devfs and thus why 
>>devfs is being abandoned as mentioned in akpm's patchset. Or as it 
>>seems, already has been abandoned.
> 
> 
> The devfs code base has been abandoned by its original
> author/maintainer.  udev has nothing to do with that.
> 
> Hope this helps,
> 
> greg k-h
> 

i didn't think udev was responsible for the lack of development, I 
assumed that was due to the lack of devfs adoption in the main stream.