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.034 / U:29.656 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site