Messages in this thread | | | Date | Sat, 9 Oct 1999 19:33:17 -0500 (CDT) | From | Oliver Xymoron <> | Subject | Re: More on bigger kdev_t |
| |
On Sat, 9 Oct 1999, Theodore Y. Ts'o wrote:
> I would suggest introducing kdev_t as a structure (and not as a pointer > to a structure) for one reason --- it makes attempts to do any kind of > mathematical or logical operations on a kdev_t painfully obvious. With > a pointer, you get a warning, but with a structure, you get compiler > error that's impossible to ignore. Given that any attempt to treat a > kdev_t in that way is a bug, you might as well have the kernel detect it > for you anyway.
I recommend integrating the device type (block or char) into the structure (or integral type). The block/char distinction is one that the kernel doesn't care about much, except that block devices have certain generic functions in their fops tables.
I recently rewrote fs/devices to use hash tables and discovered that most of the functions and arrays therein were duplicated - more or less identical functions for char and block. Having them all take a kdev_t creates a nicer, simpler interface, except the current kdev_t doesn't keep track of type. If it did, it becomes possible to throw out more than half of that code and quite a lot of other code. You can still do it, obviously, by passing around type with kdev_t, but it seems silly - kdev_t should uniquely identify a device, whether block or char.
The other part of my rewrite is to allow registering fops specific to minors - a lookup on <type major minor> will first check if a specific set of file ops exists for that device, and will then fall back to major. Remember that fops are always called with an inode that contains a kdev_t. This gets rid of the need for multiplexing functions in devices like misc and the memory/null/zero device groups. Plus, we can keep track of the names of the minors and spew them out in /proc/devices. Oh, and no more hard limits on the number of devices, obviously.
After toying with that for a bit, I discovered an even better way to do it was to map <type major minor> into a nice integer and then use Linus' resource trees to associate them with fops. Now register_dev can say things like "Give me a whole major" or "I need 16 consecutive minors" or "I just need one minor, preferably here". Didn't finish that implementation though - got bogged down in trying to prettify resources.c.
BTW, the current implementation of devices.c has no locks to protect the device tables. Probably raceable.
Something I had mentioned right before 2.2 came out was to do something similar registration for ioctls - currently numerous ioctls are cut and pasted from device to device and use a lot of very similar code. Registering ioctls would allow making a lot of these generic and many set|get ioctls could be made to use the current ioctl type macros to automatically do copy_{to|from}user. No more giant switch statements.
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |