Correct. We were just using 64 bits as an example.
> functionality only available when using glibc. Please note I haven't
> said drop support for libc5. Backward-compatibility can be achieved
> to avoid using for a new device number a device where all bits beside
> the first 16 are set. I.e., if you use
>
> 0000 0000 0000 XXXX -> old device
>
> YYYY YYYY ZZZZ XXXX -> with YYYY YYYY ZZZZ != 0000 0000 0000
> and YYYY YYYY = major
> ZZZZ XXXX = minor
>
> you can use libc5 with the old numbering.
So i_rdev would remain as 16 bits, and a new i_rdeve (extended) would
be appended to struct inode which libc 5 would not know about. This
splitting of the device number looks a bit ugly to me. It would also
break the MAJOR, MINOR and MKDEV macros in the kernel. Instead of
carrying around the kdev_t number, instead you would need to carry the
struct inode. That's going to break a lot of code.
I don't see how you could increase the size of i_rdev in the kernel's
struct inode without breaking C library compatibility, since the
library expects i_rdev to be 16 bits followed by i_size.
Also, I don't like the idea that libc 5 applications (like <fdisk>
and other useful tools) cannot access the new devices/partitions.
Finally, I don't see how your scheme can work to support more SCSI
minors. Unless you have a whole new SCSI driver on one of the "high"
majors. Yuk. That gets back to the problem of "blocking" libc 5 access
to some of your discs.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu