Hi,
On Mon, 24 Mar 2003 Andries.Brouwer@cwi.nl 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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Mar 31 2003 - 22:00:17 EST