lkml.org 
[lkml]   [2003]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: devfs to be obsloted by udev?
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.

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

\
 
 \ /
  Last update: 2005-03-22 13:48    [W:0.897 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site