> Shouldn't this be "typedef unsigned int __kernel_dev_t;" ?
This is for you to play with, not a submitted patch.
Make it int, long, long long - whatever you like.
> This is 16+16. What is involved in going to 12+20?
Editing kdev_t.h and changing one 16 to 12 and another 16 to 20.
And then there are two 0xffff, lazy as I am, that you would
have to turn into the appropriate masks: e.g., for 13+19:
#define KDEV_MINOR_BITS 19
#define KDEV_MINOR_MASK ((1<<KDEV_MINOR_BITS) - 1)
#define KDEV_MAJOR_BITS 13
#define KDEV_MAJOR_MASK ((1<<KDEV_MAJOR_BITS) - 1)
#define minor(dev) ((dev).value & KDEV_MINOR_MASK)
#define major(dev) (((dev).value >> KDEV_MINOR_BITS) & KDEV_MAJOR_MASK)
Similar in the definition of MAJOR and MINOR.
One of these weeks I'll give you a better parametrized version.
(I hope the purpose of distinguishing arithmetic types dev_t
and kdev_t is clear. The latter is simple e.g. 13+19.
mk_kdev, major, minor are simple macros. Kernel use is fast,
no conditional involved.
The former must be backwards compatible, so MKDEV, MAJOR, MINOR
are somewhat complicated macros; for example MAJOR asks: does it fit
in 16 bits? then MAJOR is the first 8; otherwise MAJOR is
the first DEV_MAJOR_BITS. Used only when converting from userspace.)
> What glibc changes are required?
Glibc has:
int
xmknod (int vers, const char *path, mode_t mode, dev_t *dev) {
unsigned short int k_dev;
k_dev = ((major (*dev) & 0xff) << 8) | (minor (*dev) & 0xff);
return INLINE_SYSCALL (mknod, 3, CHECK_STRING (path), mode, k_dev);
}
You see that even though glibc dev_t is very large, the peephole
offered with mknod is tiny. So, the glibc mknod routine must be fixed.
Also the macros major, minor, makedev in <sys/sysmacros.h>.
> What happens with an old glibc?
As long as you do not use new device numbers, all is well.
With new device numbers and an old glibc, major and minor
will be truncated to 8 bits in many places.
So, anybody who wants to use 10000 disks will also have to
use the latest glibc.
Andries
Hi,
On Wed, 19 Mar 2003 [email protected] wrote:
> (I hope the purpose of distinguishing arithmetic types dev_t
> and kdev_t is clear. The latter is simple e.g. 13+19.
> mk_kdev, major, minor are simple macros. Kernel use is fast,
> no conditional involved.
> The former must be backwards compatible, so MKDEV, MAJOR, MINOR
> are somewhat complicated macros; for example MAJOR asks: does it fit
> in 16 bits? then MAJOR is the first 8; otherwise MAJOR is
> the first DEV_MAJOR_BITS. Used only when converting from userspace.)
There is a point I'd like to get clear: where should the 16bit<->32bit
dev_t conversion happen?
I think any software that cares about this should be safe by now. That
leaves us with on-disk and on-wire formats and IMO only at these places a
conversion should happen.
The other problem is how can software create nodes for a specific device?
bye, Roman
On Thu, Mar 20, 2003 at 10:00:48PM +0100, Roman Zippel wrote:
> There is a point I'd like to get clear: where should the 16bit<->32bit
> dev_t conversion happen?
> I think any software that cares about this should be safe by now. That
> leaves us with on-disk and on-wire formats and IMO only at these places a
> conversion should happen.
Actually, no. mknod(8), ls(1), and friends still assume struct
stat with u16.
Joel
--
"Every new beginning comes from some other beginning's end."
Joel Becker
Senior Member of Technical Staff
Oracle Corporation
E-mail: [email protected]
Phone: (650) 506-8127
On Thu, Mar 20, 2003 at 01:47:41PM -0800, Joel Becker wrote:
> Actually, no. mknod(8), ls(1), and friends still assume struct
> stat with u16.
It's been pointed out to me that this isn't clear. What I mean
is that mknod(8), ls(1), and other programs assume dev_t mappings that
are usually based upon the MAJOR() macro and friends. This means that
any modification of the dev_t arrangement may require source fixes and
may not, depending on how smart MAJOR() is, but will absolutely require
a new compile of the software to pick up the new MAJOR() macro.
Peter is right, we only want to do this once.
Joel
--
"There are some experiences in life which should not be demanded
twice from any man, and one of them is listening to the Brahms Requiem."
- George Bernard Shaw
Joel Becker
Senior Member of Technical Staff
Oracle Corporation
E-mail: [email protected]
Phone: (650) 506-8127