Re: Minor numbers

Re: Minor numbers

[Andries.Brouwer]

>> The exercise is essentially the patch that I sent last month or so.

> mknod takes a 32bit input
> the stat64 padding only has room for 32bits

Hmm. You make me search for this old patch.
Since Linus' reaction was not exactly positive I left
the topic again, but there must be a copy somewhere..

Aha, found it. Mail from March 24.

==================================================================
...
- For stat all is fine already since we got stat64.
- For mknod a little work is required.
- The state of affairs with loopinfo is sad today (the fact that
kernel and glibc use dev_t of different size causes problems)
but all will be well with 64-bit dev_t.
...
(iii) mknod:
Then there is the prototype of mknod.
I changed it for all filesystems to

diff -r linux-2.4.2/linux/fs/ext2/namei.c linux-2.4.2kdevt/linux/fs/ext2/namei.c
387c387,388
< static int ext2_mknod (struct inode * dir, struct dentry *dentry, int mode, int rdev)
---
> static int ext2_mknod (struct inode * dir, struct dentry *dentry, int mode,
>                      dev_t rdev)

The system call itself cannot easily be changed to take a larger dev_t,
mostly because under old glibc the high order part would be random.
So, mknod64, with

diff linux-2.4.2/linux/fs/namei.c linux-2.4.2kdevt/linux/fs/namei.c
1205c1208
< asmlinkage long sys_mknod(const char * filename, int mode, dev_t dev)
---
> static long mknod_common(const char * filename, int mode, dev_t dev)
1245a1249,1259
> }
> 
> asmlinkage long sys_mknod64(const char * filename, int mode,
>                           unsigned int ma, unsigned int mi)
> {
>       return mknod_common(filename, mode, ((dev_t) ma << 32) | mi);
> }
...
==================================================================

Yes, so mknod is solved by having mknod64.
I saw no problems with stat64, but you do.
Hmm. I was running a system with 64-bit dev_t when I wrote that letter,
so at least for i386 there cannot be any serious problems.
Let me see.

=================== include/asm-i386/stat.h ======================
/* This matches struct stat64 in glibc2.1, hence the absolutely
 * insane amounts of padding around dev_t's.
 */
struct stat64 {
        unsigned short  st_dev;
        unsigned char   __pad0[10];
...
        unsigned short  st_rdev;
        unsigned char   __pad3[10];
...
==================================================================

So, it seems that you are too pessimistic.
The present stat64 structure even allows 96-bit dev_t.

Andries

Re: Minor numbers

[Alan Cox]

> Hmm. You make me search for this old patch.
> Since Linus' reaction was not exactly positive I left
> the topic again, but there must be a copy somewhere..

Given current real world evolution Im very interested in 32bit dev_t or at
least implementing the 'lots of majors' half of it because we are probably
going to need it in the 2.5 years before we have a 2.6

> The system call itself cannot easily be changed to take a larger dev_t,
> mostly because under old glibc the high order part would be random.

Is that true or is it always happening to be clear ? I was rather hoping all
C libraries happened to clear the upper half 

Minor Numbers

[sah]

Greetings,

I'm curious as to the status of minor number extension
in the 2.5 kernel series.  Currently my 2.4 kernel uses
an 8-bit minor number; how is the development going to
extend this to 16 or even 32 bits?

Cheers,

Sam Hopkins
sah@coraid.com

Re: Minor numbers

[Andries.Brouwer]

> Im very interested in 32bit dev_t or at least implementing
> the 'lots of majors' half of it because we are probably
> going to need it in the 2.5 years before we have a 2.6

Yes, a larger dev_t has been desirable for a long time,
and more and more kludges are invented to work around its lack.
Still, changing this is fairly simple.

I firmly believe that we want to go to 64-bit. In case there
is an intermediate step, that means that it would have to be 16+16,
in order not to introduce complications later.

>> The system call itself cannot easily be changed to take a larger dev_t,
>> mostly because under old glibc the high order part would be random.

> Is that true or is it always happening to be clear ?

I wrote that talking about 64-bit dev_t. For 32-bit one might be
slightly more optimistic. The C calling conventions will widen a
short to an int, I suppose.
It is true however that older glibc does its best to make sure
the kernel doesnt see more than 16 bits:

  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 __syscall_mknod (path, mode, k_dev);
  }

Andries

Re: Minor numbers

[Andries.Brouwer]

> The fs and stat structs are set up to allow 32bits.
> 64bits is a major exercise

No. Inside the kernel the dev_t type does not really occur.
The exercise is essentially the patch that I sent last month or so.

Andries

Re: Minor numbers

[Alan Cox]

> No. Inside the kernel the dev_t type does not really occur.
> The exercise is essentially the patch that I sent last month or so.

mknod takes a 32bit input
the stat64 padding only has room for 32bits

The kernel representation internally I dont care about, its probably a pointer
not a 32:32 though

Re: Minor numbers

[Andries.Brouwer]

>>> 20:12 is more common

>> Which is major, which is minor?

> 20bit major

That is not more common. Around us we see major:minor splits
8:24, 12:20, 14:18. If we want to use NFSv3 and communicate
with all these systems we would do wise to use 32:32.

[Reminds me of a discussion that ended unfinished.
Stage 1: "64 bits? Never in hell!"
Answer 1: These 64 bits do not make the kernel slow.
  Indeed, the kernel uses a 32-bit pointer.
Stage 2: "but I am on a holy crusade"
Answer 2: These bits are not about bloat but about the width of
  the communication channel between user space and filesystem.
Stage 3: <silence so far>
Wonder whether Linus still objects. Let me cc him.]

Andries

Re: Minor numbers

[Alan Cox]

> That is not more common. Around us we see major:minor splits
> 8:24, 12:20, 14:18. If we want to use NFSv3 and communicate
> with all these systems we would do wise to use 32:32.

My error. 32:32 is however not interesting. The fs and stat structs
are set up to allow 32bits. 64bits is a major exercise

> 

Minor numbers

[Alex Q Chen]

To the best of my knowledge, dev_t number is still 16 bits with 8 most
significant bits being the major number and the other 8 bits being the
minor number; which of course means that minor numbers can only go up to
255.  Has this limitation been some how addressed with 2.4?  256 devices
per module, sometimes is not enough, especially if you are in the SAN
environment; or when the 256 minors numbers are broken down to several
ranges of numbers to address different types of special files.  I don't see
how this problem can be solved with dev_fs either.  Anyone out there with a
work-around or is proposing a solution?  I believe that minor and major
numbers for SUN and AIX are both 16 bits each (32 bits dev_t).

Thanks in advance for your input.

Thanks!

Sincerely,
Alex Chen

IBM SSD Device Driver Development
Office: 9000 S. Rita Rd 9032/2262
Email: aqchen@us.ibm.com
Phone: (external) 520-799-5212 (Tie Line) (321)-5212

Re: Minor numbers

[Alan Cox]

> 255.  Has this limitation been some how addressed with 2.4?  256 devices
> per module, sometimes is not enough, especially if you are in the SAN
> environment; or when the 256 minors numbers are broken down to several

2.4 is using 16bit dev_t in kernel still. Application space sees a much
larger dev_t so we can make the move in 2.5 very easily

> work-around or is proposing a solution?  I believe that minor and major
> numbers for SUN and AIX are both 16 bits each (32 bits dev_t).

20:12 is more common

Re: Minor numbers

[Rogier Wolff]

Alan Cox wrote:
> > 255.  Has this limitation been some how addressed with 2.4?  256 devices
> > per module, sometimes is not enough, especially if you are in the SAN
> > environment; or when the 256 minors numbers are broken down to several
> 
> 2.4 is using 16bit dev_t in kernel still. Application space sees a much
> larger dev_t so we can make the move in 2.5 very easily
> 
> > work-around or is proposing a solution?  I believe that minor and major
> > numbers for SUN and AIX are both 16 bits each (32 bits dev_t).
> 
> 20:12 is more common

Which is major, which is minor?

I have one (private) driver that requires around 5000 minors.
(currently through some 20 majors) (Currently only just over half of
these are physically installed....)

			Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 

Re: Minor numbers

[Alan Cox]

> > 20:12 is more common
> 
> Which is major, which is minor?

20bit major

> I have one (private) driver that requires around 5000 minors.
> (currently through some 20 majors) (Currently only just over half of
> these are physically installed....)

Just use several. The split is a bit vague in modern OS's - because its
really now heirarchical in many of them - eg the solaris  controller, bus,
unit, lun, .. thing.

I guess it went the way of classed addressing

Re: Minor numbers

[H. Peter Anvin]

Followup to:  <E14zJmj-0000p3-00@the-village.bc.nu>
By author:    Alan Cox <alan@lxorguk.ukuu.org.uk>
In newsgroup: linux.dev.kernel
>
> > > 20:12 is more common
> > 
> > Which is major, which is minor?
> 
> 20bit major
> 

Surely you're jesting?

12 bit major, 20 bit minor is the only logical split.  The need for
minors (think individual disks) is much greater than the need for
majors.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: Minor numbers

[Joel Becker]

On Mon, May 14, 2001 at 03:57:21PM +0100, Alan Cox wrote:
> > > 20:12 is more common
> > 
> > Which is major, which is minor?
> 
> 20bit major

	Well, AIX 4.3 (and 4.[12] I think as well) uses 16:16, and they
are preparing for 32:32 when the kernel finaly goes fully 64-bit.  I
don't know enough about AIX 5.1 to know if they really did that or
backed down on their promise (The kernel guys told me two years ago that
they were going to push the full 64-bit migration, but I haven't heard
anything since).

Joel

-- 

"We'd better get back, `cause it'll be dark soon,
 and they mostly come at night.  Mostly."

			http://www.jlbec.org/
			jlbec@evilplan.org