Re: Getting past the 16-bit dev_t limitation.

From: John Byrne (jbyrne@kahuna.cag.cpqcorp.net)
Date: Mon Sep 18 2000 - 17:41:11 EST


"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/



This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:18 EST