> 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 majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/