devfs to be obsloted by udev?

devfs to be obsloted by udev?

[Ed Sweetman]

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

Re: devfs to be obsloted by udev?

[Ed Sweetman]

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.

Re: devfs to be obsloted by udev?

[Greg KH]

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

Re: devfs to be obsloted by udev?

[Greg KH]

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

Re: devfs to be obsloted by udev?

[Bartlomiej Zolnierkiewicz]

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.

Re: devfs to be obsloted by udev?

[Kurt Wall]

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.

Re: devfs to be obsloted by udev?

[Justin Cormack]

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

Re: devfs to be obsloted by udev?

[Greg KH]

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

Re: devfs to be obsloted by udev?

[Bryan O'Sullivan]

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

Re: devfs to be obsloted by udev?

[Sam Ravnborg]

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

Re: devfs to be obsloted by udev?

[Bryan O'Sullivan]

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