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