lkml.org 
[lkml]   [1999]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectMore on bigger kdev_t
After looking at kdev_t and existing code some more, I think that it
should be an unsigned long. Reasons:

* making kdev_t a struct, or a pointer to a struct, complicates
assignment of kdev_t values
* tons of existing code stores a device number in a 32-bit var, and
passes this value into to_kdev_t() inline function
* making kdev_t an unsigned long allows growth and 32-bit major/minor
numbers on 64-bit platforms

I experimented a bit with kdev_t.h patches and found that a 32-bit
kdev_t was quite easy to add, and very compatible with existing code.

The main problem was boot loaders, such as the kernel boot sector which
uses a word (16-bit) to store the root device major/minor number. I
overcame this by defining kdev_t conversions which supported various
sizes of kdev_t values:

u16_to_kdev_t() converts 8-bit major/minor to 16-bit
u32_to_kdev_t() converts 16-bit major/minor to 32-bit on AXP, IA64
u64_to_kdev_t() converts 32-bit major/minor to 16-bit on IA32

This solution keeps most of userland, such as LILO, binary compatible.
mknod, ls, and such will of course have to be recompiled.

Jeff




--
Custom driver development | Never worry about theory as long
Open source programming | as the machinery does what it's
| supposed to do. -- R. A. Heinlein

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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