Re: 32bit dev_t

Re: 32bit dev_t

[Andries.Brouwer]

> Who is tracking the 32bit dev_t effort for 2.5?

Once or twice a year I build a kernel with 32bit or 64bit dev_t.
Every now and then submit a few patches so that doing so
remains easy. The last real change was the change in prototype
of the VFS *_mknod functions.

: 32bit dev_t IMHO is essential to 2.6. Essential enough that if its not
: in the base 2.6 all the vendors have to get together and issue a Linus 
: incompatible but common 32bit dev_t interface.

The main point to decide would be the external dev_t format.
Of course the format must be compatible with existing filesystems
and binaries. For example,

#define MAJOR(dev)      ((unsigned int)(((dev) & 0xffff0000) \
	? ((dev) >> 16) & 0xffff : ((dev) >> 8) & 0xff))
#define MINOR(dev)      ((unsigned int)(((dev) & 0xffff0000) \
	? ((dev) & 0xffff) : ((dev) & 0xff)))
#define MKDEV(ma,mi)    ((dev_t)((((ma) & ~0xff) == 0 && ((mi) & ~0xff) == 0) \
	? (((ma) << 8) | (mi)) : (((ma) << 16) | (mi))))

This is 1-1 on nonzero majors (and zero major, 8-bit minor).

Once the decision has been made on the size of dev_t and the
computation of major,minor given a dev_t, it is straightforward
to implement that decision. Unfortunately not only the kernel
but also glibc must be changed.

In glibc one needs to fix in sysdeps/unix/sysv/linux
the files sys/sysmacros.h, bits/stat.h, ustat.c, xmknod.c.

In the kernel there are lots of tiny fixes needed because
people did not distinguish between int and dev_t and kdev_t.
Nothing major.

(Anyone can boot a 2.5 kernel with 32-bit dev_t by changing
    include/asm-i386/posix_types.h
(change the line "typedef unsigned short __kernel_dev_t;"
to what is desired, e.g. s/short/int/) and changing
    include/linux/kdev_t.h
(change the typedef for kdev_t to have e.g. unsigned int,
set KDEV_MINOR_BITS and KDEV_MAJOR_BITS to 16,
change the 0xff in the definition of major and minor to 0xffff,
change the definitions of MAJOR, MINOR, MKDEV as above).)

[Warning: I do such things and it works. But if you do so,
it may well destroy your filesystems. A complete patch has
minor fixes all over the place.]


Andries

Re: 32bit dev_t

[Joel Becker]

On Fri, Jan 24, 2003 at 11:04:45PM +0100, Andries.Brouwer@cwi.nl wrote:
> Once or twice a year I build a kernel with 32bit or 64bit dev_t.
> Every now and then submit a few patches so that doing so
> remains easy. The last real change was the change in prototype
> of the VFS *_mknod functions.

	It's good to know that the actual changes are small, but I was
specifically wondering what the status was as far as inclusion.  If
there are issues, what are they?  Etc.

Joel

-- 

"In the arms of the angel, fly away from here,
 From this dark, cold hotel room and the endlessness that you fear.
 You are pulled from the wreckage of your silent reverie.
 In the arms of the angel, may you find some comfort here."

Joel Becker
Senior Member of Technical Staff
Oracle Corporation
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

Re: 32bit dev_t

[H. Peter Anvin]

Followup to:  <UTC200301242204.h0OM4jU09451.aeb@smtp.cwi.nl>
By author:    Andries.Brouwer@cwi.nl
In newsgroup: linux.dev.kernel
> 
> The main point to decide would be the external dev_t format.
> Of course the format must be compatible with existing filesystems
> and binaries. For example,
> 
> #define MAJOR(dev)      ((unsigned int)(((dev) & 0xffff0000) \
> 	? ((dev) >> 16) & 0xffff : ((dev) >> 8) & 0xff))
> #define MINOR(dev)      ((unsigned int)(((dev) & 0xffff0000) \
> 	? ((dev) & 0xffff) : ((dev) & 0xff)))
> #define MKDEV(ma,mi)    ((dev_t)((((ma) & ~0xff) == 0 && ((mi) & ~0xff) == 0) \
> 	? (((ma) << 8) | (mi)) : (((ma) << 16) | (mi))))
> 
> This is 1-1 on nonzero majors (and zero major, 8-bit minor).
> 

I thought we had already decided:

	12 bits major : 20 bits minor

The zero major is used for dev_t compatibility, of course.

I personally still prefer 32:32, but I got voted down.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: cris ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

32bit dev_t

[Joel Becker]

Folks,
	Who is tracking the 32bit dev_t effort for 2.5?  There are
already existing installations with 500 to 1000 disks attached to a
system, and I don't know that Linux really wants to wait four years to
get there!
	If someone could point me to a current patch or any current
information about the issues, I'd really appreciate it.

Joel

-- 

Life's Little Instruction Book #182

	"Be romantic."

Joel Becker
Senior Member of Technical Staff
Oracle Corporation
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

Re: 32bit dev_t

[Steven Dake]

Joel,

Linux doesn't really need a 32 bit kdev_t structure to support 1000 
disks.  There is plenty of device space available to support over 1500 
disks by modifying the linux scsi layer.

Thanks
-steve

Joel Becker wrote:

>Folks,
>	Who is tracking the 32bit dev_t effort for 2.5?  There are
>already existing installations with 500 to 1000 disks attached to a
>system, and I don't know that Linux really wants to wait four years to
>get there!
>	If someone could point me to a current patch or any current
>information about the issues, I'd really appreciate it.
>
>Joel
>
>  
>

Re: 32bit dev_t

[Joel Becker]

On Tue, Jan 21, 2003 at 02:29:17PM -0700, Steven Dake wrote:
> Linux doesn't really need a 32 bit kdev_t structure to support 1000 
> disks.  There is plenty of device space available to support over 1500 
> disks by modifying the linux scsi layer.

	First, that's an approach that removes space from other devices.
In addition, I suspect we'll see 2000 disk systems before we see 2.8.

Joel


-- 

"I am working for the time when unqualified blacks, browns, and
 women join the unqualified men in running our overnment."
	- Sissy Farenthold

Joel Becker
Senior Member of Technical Staff
Oracle Corporation
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

Re: 32bit dev_t

[Jeff Garzik]

On Tue, Jan 21, 2003 at 01:56:02PM -0800, Joel Becker wrote:
> On Tue, Jan 21, 2003 at 02:29:17PM -0700, Steven Dake wrote:
> > Linux doesn't really need a 32 bit kdev_t structure to support 1000 
> > disks.  There is plenty of device space available to support over 1500 
> > disks by modifying the linux scsi layer.
> 
> 	First, that's an approach that removes space from other devices.
> In addition, I suspect we'll see 2000 disk systems before we see 2.8.


Of course, we know the solution is /dev/disk, as mentioned by Linus at
least a couple times, which eliminates a lot of dev_t limitation
issues...  :)

	Jeff

Re: 32bit dev_t

[Alan]

On Tue, 2003-01-21 at 21:29, Steven Dake wrote:
> Joel,
> 
> Linux doesn't really need a 32 bit kdev_t structure to support 1000 
> disks.  There is plenty of device space available to support over 1500 
> disks by modifying the linux scsi layer.

You run out of assigned major/minor numbers. There is a sick hack that
steals other device idents but thats not usable in a production environment.
32bit dev_t IMHO is essential to 2.6. Essential enough that if its not in
the base 2.6 all the vendors have to get together and issue a Linus 
incompatible but common 32bit dev_t interface.