Messages in this thread |  | | Date | Thu, 24 May 2001 17:20:27 +0200 | From | Marko Kreen <> | Subject | CHR/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/
|  |