Maybe you didnt understand what I meant.
both bdev and cdev take care of the correspondence
device number <---> struct with operations.
The operations are different, but all bdev/cdev code is identical.
So the choice is between two uglies:
(i) have some not entirely trivial amount of code twice in the kernel
(ii) have a union at the point where the struct operations
I preferred the union.
>> And a second remark: don't forget that presently the point where
>> bdev is introduced is not quite right. We must only introduce it
>> when we really have a device, not when there only is a device
>> number (like on a mknod call).
> That's simply wrong. kdev_t is used for unopened objects quite often.
Yes, but that was my design mistake in 1995.
I think you'll find if you continue on this way,
as I found and already wrote in kdev_t.h
that it is bad to carry pointers around for unopened and unknown devices.
So, I think that the setup must be changed a tiny little bit
and distinguish meaningless numbers from devices.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/