CHR/BLK needed? was: Re: Why side-effects on open...

Marko Kreen
2001-05-24T15:18:17Z

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