OK, I don't understand how this could work. Could you please show
exactly what changes you would make to the kernel struct inode?
> > Also, I don't like the idea that libc 5 applications (like <fdisk>
> > and other useful tools) cannot access the new devices/partitions.
>
> Of course not. This will break in any case.
>
> > 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.
>
> With libc5 you will never be able to change the device numbering. See
> above, you agreed already. So the remaining question is how to keep
> libc5 alive on new kernels which don't need many SCSI IDs etc, i.e.,
> in situations which can be handled now.
That's the point. I don't like blocking libc 5 access to the 17th SCSI
disc. We don't *have* to do that. There is a way of supporting more
than 16 SCSI discs and *still* give access to all those discs with
libc 5. The same scheme would even work for for libc 4.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu