Messages in this thread | | | Date | Sat, 10 Jan 1998 09:44:12 +1100 | From | Richard Gooch <> | Subject | Re: 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....
| |