[lkml]   [2001]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:53    [W:0.226 / U:0.656 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site