lkml.org 
[lkml]   [1998]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: devlinks: an alternative to devfs
Andrea Arcangeli writes:
> On Fri, 9 Jan 1998, Martin von Loewis wrote:
>
> >> Excuse my ignorance (I know that sure I am missing something), but why
> >> don' t change in /usr/src/linux/include/linux/kdev_t.h from:
> >>
> >> typedef unsigned short kdev_t;
> >>
> >> to:
> >>
> >> typedef unsigned int kdev_t;
> >>
> >> and we will have magically space for 16 bit minor and major numbers. Then
> >> we need to change MINORBITS to 16 and all others 8 to 16...
> >
> >For the last part, there has been an acceptable work-around for a
> >couple of years, so you don't have to recompile all your applications
> >- only when they try to stat(2) files with majors >256, they'll run
> >into problems. For the other items, there have been proposed
> >work-arounds, but no steps have been taken. Since this is a major
> >change, people discuss using 64 bits for dev_t, to get it right in the
> >long run. Unfortunately, this further complicates things, as some of
> >the proposed solutions won't work anymore.
>
> My opinion is to take this hard but right way. devfs is _the_ workaround.
> `typedef unsinged int kdev_t' is the right thing to do, since unsigned int
> will define a 64 bit variable after 2038. When more than 4 giga of devices
> will be connected to linux, linux will be able to recompile all the
> software and autopatch itself to handle 2^64 devices major and minor
> numbers in less than one nsec :).

There is a scalability problem with large major and minor
numbers. Stepping from an inode to the driver file_operations will
require a search. Check out drivers/char/misc.c to see what I
mean. This is the future with 16+ bit majors.

Regards,

Richard....

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