It appears that devfs is to be replaced by the use of udev in the not so
distant future. 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? I dont see the real benefit in
having two directories that basically give the same info. 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. 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.
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.
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?
> 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.
> 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
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.
initramfs
On Tuesday 02 of September 2003 16:09, Ed Sweetman wrote:
> It appears that devfs is to be replaced by the use of udev in the not so
> distant future. 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? I dont see the real benefit in
> having two directories that basically give the same info. 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. 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.
>
> 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.
On Tue, Sep 02, 2003 at 10:32:20AM -0400, Ed Sweetman wrote:
> >>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.
That's my suggestion today if you want to have a machine that's usable
:)
greg k-h
Quoth Ed Sweetman:
>
> 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.
>From here, devfs seemed simply to orphaned. I know lots of people
using it, but it's getting kinda crufty...
Kurt
--
Leibowitz's Rule:
When hammering a nail, you will never hit your finger if you
hold the hammer with both hands.
On Tue, 2003-09-02 at 21:19, Bartlomiej Zolnierkiewicz wrote:
>
> initramfs
which seems to have been postponed to 2.7.
> On Tuesday 02 of September 2003 16:09, Ed Sweetman wrote:
> > It appears that devfs is to be replaced by the use of udev in the not so
> > distant future. 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? I dont see the real benefit in
> > having two directories that basically give the same info. 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. 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.
> >
> > 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.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Wed, Sep 03, 2003 at 10:38:48AM +0100, Justin Cormack wrote:
> On Tue, 2003-09-02 at 21:19, Bartlomiej Zolnierkiewicz wrote:
> >
> > initramfs
>
> which seems to have been postponed to 2.7.
No, the initramfs code is in 2.6 right now. The boot processes uses it
too.
What has been postponed to 2.7 is the moving of some of the boot code to
use it some more. But that's really just a matter of someone doing the
work (and adding it to the build process properly.) There are a few
patches floating around somewhere that do this with the exception of
intregrating into the build.
thanks,
greg k-h
On Wed, 2003-09-03 at 11:41, Greg KH wrote:
> What has been postponed to 2.7 is the moving of some of the boot code to
> use it some more. But that's really just a matter of someone doing the
> work (and adding it to the build process properly.) There are a few
> patches floating around somewhere that do this with the exception of
> intregrating into the build.
Actually, much of the work is both done and integrated into the build
already.
See http://klibc.bkbits.net/2.5-klibc for a kernel that has this stuff
in place.
<b
On Wed, Sep 03, 2003 at 11:41:40AM -0700, Greg KH wrote:
> What has been postponed to 2.7 is the moving of some of the boot code to
> use it some more. But that's really just a matter of someone doing the
> work (and adding it to the build process properly.) There are a few
> patches floating around somewhere that do this with the exception of
> intregrating into the build.
Can some one sched a bit more light on what is seeked to get it integrated
in the build. Kai G. did a big update in this area some time ago -
but maybe more is needed?
I could give the build issue a spin.
Sam
On Wed, 2003-09-03 at 12:17, Sam Ravnborg wrote:
> Can some one sched a bit more light on what is seeked to get it integrated
> in the build.
See my previous response to Greg.
The only outstanding build issue is that the userspace stuff gets
rebuilt unconditionally on every make, and I don't know why. You're
welcome to clone the repo at http://klibc.bkbits.net:8080/2.5-klibc and
figure it out.
> Kai G. did a big update in this area some time ago -
> but maybe more is needed?
The build integration in the repo above is based on Kai's changes,
forward ported from 2.5.60 or so. You are more than welcome to prettify
the hacking I had to do to get it working.
<b