Re: Lots of SCSI-disks, how?!

Richard Gooch (Richard.Gooch@atnf.CSIRO.AU)
Wed, 22 Apr 1998 12:35:52 +1000


Ulrich Drepper writes:
> Richard Gooch <Richard.Gooch@atnf.CSIRO.AU> writes:
>
> > There's still plently of people using libc 5 (and for good
> > reasons!). I think there's even people using libc 4. If 2.3 were to
> > introduce a 64 bit dev_t, it would stuff these people up, I think.
> > While you could perhaps argue that libc 4 is so ancient that it
> > doesn't have to be supported with kernel 2.3, I don't think libc 5
> > compatibility should be broken yet.
>
> But even if you change dev_t to only 32bits you will break libc5
> compatibility. You either stick with 16bits or make the new

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