lkml.org 
[lkml]   [1999]   [Oct]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

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