[lkml]   [2003]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/3] revert register_chrdev_region change

On Mon, 24 Mar 2003 wrote:

> > I'm personally not yet completly happy with his interface either
> > because he still uses the major/minor split
> Yes, it is more elegant to register one or more ranges.
> (But ranges of what? Ranges in dev_t space? Or in kdev_t space?

Ok, I'm slightly confused now, what is the difference between the "dev_t
space" and the "kdev_t space"? The answer I'd like to hear is: none.
A difference might be the encoding, that's why I mentioned the ext2
example. How will be e.g. 0x0301 encoded on disk with your changes?
So far I understood kdev_t as a marker, which has to be replaced with
either struct block_device or char_device, so that at some point kdev_t
goes away completely. (Especially Al did some great work here with the
block layer.) You removed now part of this work by removing the i_cdev
pointer from the inode. What will you replace it with?

> Also, you'll notice that the current simple hash scheme is insufficient
> if we want to have subranges that override larger ranges.
> But life is easier if we postpone that discussion a bit.

I'd prefer to have the discussion now, as I still don't know what we need
ranges or even subranges for. What problem are you trying to solve?

> # It would help a lot if you would explain what the next stages are.
> - Polish the kernel until a change of the size of dev_t is possible.
> - Agree on a new size for dev_t, major, minor. Make the change.
> - Ask Ulrich to update glibc.

I don't care much about the specific major/minor encoding, I want to know
how it will be used at the kernel level.

bye, Roman

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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