lkml.org 
[lkml]   [2001]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectCHR/BLK needed? was: Re: Why side-effects on open...
    On Thu, May 24, 2001 at 09:39:35AM -0500, Oliver Xymoron wrote:
    > On Thu, 24 May 2001, Marko Kreen wrote:
    > > IMHO the CHR/BLK is not needed. Think of /proc. In the future,
    > > the backup tools will be told to ignore /dev, that's all.
    >
    > The /dev dir should not be special. At least not to the kernel. I have
    > device files in places other than /dev, and you probably do too (hint:
    > anonymous FTP).

    So? Do you allow downloading from/to /dev in your chrooted ftp?

    Ofcourse this is not hard-wired or something. You tell devfsd
    to put dev's somewhere. Next moment you edit backup config
    and tell it to igrore that /somewhere. As I said: like /proc
    currently is. Or should current /proc converted to CHR devices?

    My idea is (well, 'devfs2' - I have the core almost working now)
    that the 'devices' will be VFS only objects - they live
    only in inode cache (on ramfs). So the CHR/BLK flags are only
    backwards compatibility for supporting major:minors for /dev on
    eg ext2. Currently I think exposing device inodes as ordinary
    files (or dirs if needed), so they look like any file to
    programs. Will this break too much? Another variant would be
    to expose them as S_IFDEV - which probably breaks even more.


    --
    marko

    -
    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 12:53    [W:6.395 / U:0.056 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site