Messages in this thread |  | | Date | Mon, 18 Sep 2000 15:41:11 -0700 | From | John Byrne <> | Subject | Re: Getting past the 16-bit dev_t limitation. |
| |
"H. Peter Anvin" wrote: > > Followup to: <39C1637B.8945251A@kahuna.cag.cpqcorp.net> > By author: John Byrne <jbyrne@kahuna.cag.cpqcorp.net> > In newsgroup: linux.dev.kernel > > > > Anyway, one of the things I was hoping to find out by going to > > linux-kernel was if there was anything other than devfs in the offing: > > such a larger dev_t. So if anyone wants to chime in on things other than > > devfs, I'd certainly like to hear about it. > > > > A larger dev_t is a "must have" item for 2.5. > > -hpa
A couple of last details (sorry for being such a slug in following up):
1.) Any decision on what the bigger dev_t will be? 16-bit major and 16-bit minor, for example?
2.) Are there any plans to try to change the user dev_t to an opaque type? Grepping through the Redhat distribution's application sources reveals several things that compare major numbers determine the type of the device. (Some explictly hardcoded; others use the constants in linux/major.h, but compare several majors for IDE/SCSI.) To me, this kind of explicit knowledge compiled into applications is something to be avoided; even when there are relatively few applications that do this. Of course, there is a strong argument for KISS, here: most of these applications should work with a simple recompilation and the need for multiple majors will be reduced once the bigger dev_t is introduced.
Thanks,
John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |