> Basically you seem to be saying
> "void * is cool" (aka kdev_t is basically an opaque magic).
Well, kdev_t is just as opaque as struct inode *.
One refers to what you want to know about a block device.
The other to what you want to know about an inode.
> I don't see what it gains you over "struct block_device *".
That is difficult to say, since the present struct block_device
still has a long way to go. At present it has no facilities
for storing data. Maybe the final results would be the same.
My main objective has always been to do a mechanical,
correctness preserving change (as the first and major step).
This means that very early on the road the objectives
"no arrays" and "large device numbers" are achieved.
Afterwards one can continue restructuring and polishing
as desired. Al's approach (as I understand it) will
achieve the same things, but later, and with more handwork.
Andries
-
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 : Sat Dec 15 2001 - 21:00:19 EST