lkml.org 
[lkml]   [2000]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 12:39    [W:0.099 / U:0.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site