Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!uunet!usc!rpi!psinntp!psinntp!uuneo!sugar!peter From: peter@NeoSoft.com (Peter da Silva) Subject: Re: Some ideas on the driver interface (yet another idea!) Organization: NeoSoft Communications Services -- (713) 684-5900 Date: Sat, 20 Mar 1993 13:39:03 GMT Message-ID: <C46wL4.360@sugar.neosoft.com> References: <1o9l9u$nn@tricky.wft.stack.urc.tue.nl> <1993Mar19.074044.18995@gmd.de> <1ocqkh$lm4@umd5.umd.edu> Lines: 28 In article <1ocqkh$lm4@umd5.umd.edu> mark@roissy.umd.edu (Mark Sienkiewicz) writes: > There is enough space in the inode that you could be storing a string > instead of a major number. When you open a device file, it could fetch > this string from the inode and look it up in a table in the kernel. Cache > the inode-to-device lookup, and you have the equivalent of a dynamically > assigned major number. That's cool. I'd suggest you do this with a *new* set of flags on the inode, so you can run the old and new methods concurrently. If you can't find any more space in the st_flags (likely), set the high bit of the major number, and use the remaining 15 bits as the minor (yet another advantage). > - it doesn't work over NFS (neither does anything else) We should be working on a better network file system anyway... one that gives full, stateful, UNIX semantics to remote files. The only political problem I can see is code that depends on the old behaviour. (stuff that grovels around in /dev) Using an unambiguous flag (like the high bit of the major number, which would raise a red flag to anyone seeing it anyway) avoids this, and allows you to keep old-style device entries if you should need them. -- Peter da Silva. <peter@sugar.neosoft.com>. `-_-' Oletko halannut suttasi tänään? 'U` Tarjoilija, tämä ateria elää vielä.