[lkml]   [1999]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] dynamic char and block devices
On Wed, 13 Oct 1999, Jeff Garzik wrote:

> Oliver Xymoron wrote:
> > I realized when I'd finished this that resource trees were an even better
> > way to go. It allows us to say things like major x minors a-b use these
> > fileops while major x minors c-d use these other fileops. It also allows
> > register_device to be _much_ smarter about how it allocates things - you
> > can say "please give me a whole major", "please give me 8 minors", any
> > granularity you'd like. The divide between majors and minors becomes a
> > continuum. Think of it as CIDR for device space.
> Very nifty idea. See why I like the new resource code? :)

Yes. Though it might need a few more primitives to fully realize its
usefulness. My tinkering to make it more flexible isn't getting anywhere -
I wrote a find_resource to either find a resource or find its tree
insertion point, which is now the core of __request_resource. However,
because the list of siblings is singly-linked, it ended up taking a struct
resource ***. Too sick to live.

Linus, would you consider a patch to make resource siblings doubly-linked?
We could then use the list macros and avoid the pointer to a pointer stuff
in the current code. Alternately, a tree.h might not be a bad idea.

> Anyway, something like this seems to imply that you would have to change
> the prototype of register_chrdev and register_blkdev. Is this correct?

No, they remain the same. My patch makes those two thin wrappers around a
generic register_dev function just like your patch does. All my new
functions take a kdev_t and a device type (block/char). I'd like a future
kdev_t to include a bit indicating type, which would make this even
cleaner. Block and char devices work more or less identically from the pov
of most of the kernel.

"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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:54    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean