Re: devfs to be obsloted by udev?
From: Ed Sweetman
Date: Tue Sep 02 2003 - 13:35:23 EST
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@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/