I hate the staged approach too, because I think it becomes a maintenance
nightmare.
Compare this to the mm re-write: we broke just about every filesystem out
there, and we didn't much care. For example, as long as ext2 and NFS works
for me, I'm pretty happy, and being explicitly broken means that people
WILL fix them (unlike the "let's write ugly #ifdef infrastructure and hope
that other people will fix up _their_ stuff to be as ugly, and then switch
over in one big splash").
The device thing is going to be different, yet similar. Breaking things is
completely acceptable, if it is for a good reason, and if _enough_ things
are fixed up that many people can play with it and incrementally fix stuff
up until everything works again.
> Now I had as goal on the one hand creation of device structs, on the other
> hand allowing large minors, a bonus that comes for free. You seem to want
> block device structs only. That makes things a bit easier but of course
> reaches only one of the two goals.
I do want character devices too, but I think we should consider block
devices and character devices to be completely separate things.
Not only are the number mappings different: character device X,Y is NOT
necessarily the same as block device X,Y at all - it may be true that for
certain "raw" devices you'll find a 1:1 mapping, but for other things you
will not. For example, the ramdisk (block device) shares the major number
with the misc devices (character device), and that should cause no
confusion at all. In fact, they should be explicitly very different, I
think.
The other reason to do block devices separately is that that way you CAN
try to make this a staged process. Only break block devices (and most
people only care about IDE and SCSI - it's ok to temporarily even break
floppies etc), and not worry about breaking the tty layer. Then later, we
can do only the character devices, and now we don't need to worry about
ll_rw_block.c, for example.
In the end, we may actually end up using the same kind of structure: maybe
both the block and the character devices will be able to use a unified
structure after all. But I don't think that is necessarily true at all,
and I don't think we should design for it.
Linus
-
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/