Re: major/minor split

Re: major/minor split

[Andries.Brouwer]

> There is a point I'd like to get clear: where should the
> 16bit<->32bit dev_t conversion happen?

I am not sure I understand the question, but if I do
the answer is "nowhere", there is no conversion
(other than the lengthening that happens when one
casts an unsigned short to an unsigned int).

For dev_t (8,1) is 0x00000801, but (8,256) is 0x00080100.
(In case of a 16+16 split. Not that I advocate that,
it is just easy talking.)

For kdev_t (8,1) is 0x00080001 and (8,256) is 0x00080100.
So kdev_t allows simple fast composition and decomposition,
but is restricted to the kernel.
While dev_t requires a conditional, since it has to remain
compatible with the old 8+8 userspace.

> how can software create nodes for a specific device?

You do not mean using mknod?

Andries

Re: major/minor split

[Roman Zippel]

Hi,

On Thu, 20 Mar 2003 Andries.Brouwer@cwi.nl wrote:

> > There is a point I'd like to get clear: where should the
> > 16bit<->32bit dev_t conversion happen?
> 
> I am not sure I understand the question, but if I do
> the answer is "nowhere", there is no conversion
> (other than the lengthening that happens when one
> casts an unsigned short to an unsigned int).

Let's look at ext2:

	if (S_ISCHR(inode->i_mode) || S_ISBLK(inode->i_mode))
		raw_inode->i_block[0] = cpu_to_le32(kdev_t_to_nr(inode->i_rdev));

Should the saved device number be a 16bit or a 32bit device number? Has 
the user any control over it?

> > how can software create nodes for a specific device?
> 
> You do not mean using mknod?

I mean via mknod, e.g. if the user has a major/minor number, how should it 
be converted to a dev_t number?

bye, Roman

Re: major/minor split

[H. Peter Anvin]

Followup to:  <Pine.LNX.4.44.0303210016360.5042-100000@serv>
By author:    Roman Zippel <zippel@linux-m68k.org>
In newsgroup: linux.dev.kernel
> 
> I mean via mknod, e.g. if the user has a major/minor number, how should it 
> be converted to a dev_t number?
> 

Using MKDEV().  Basically, use the old format if it fits (for
compatibility), otherwise the new format.

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

Re: major/minor split

[H. Peter Anvin]

Followup to:  <UTC200303202224.h2KMOXC01107.aeb@smtp.cwi.nl>
By author:    Andries.Brouwer@cwi.nl
In newsgroup: linux.dev.kernel
> 
> For kdev_t (8,1) is 0x00080001 and (8,256) is 0x00080100.
> So kdev_t allows simple fast composition and decomposition,
> but is restricted to the kernel.
> While dev_t requires a conditional, since it has to remain
> compatible with the old 8+8 userspace.
> 

I would suggest, instead:

typedef struct kdev {
       u32 major, minor;
} kdev_t;

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

Re: major/minor split

[Andries.Brouwer]

    From: Roman Zippel <zippel@linux-m68k.org>

    > > There is a point I'd like to get clear: where should the
    > > 16bit<->32bit dev_t conversion happen?
    > 
    > ..., there is no conversion
    > (other than the lengthening that happens when one
    > casts an unsigned short to an unsigned int).

    Let's look at ext2:

        if (S_ISCHR(inode->i_mode) || S_ISBLK(inode->i_mode))
            raw_inode->i_block[0] = cpu_to_le32(kdev_t_to_nr(inode->i_rdev));

    Should the saved device number be a 16bit or a 32bit device number?
    Has the user any control over it?

It used to be a 32-bit device number. If we want to store
a 64-bit device number then also raw_inode->i_block[1]
is used. Fortunately ext2 has lots of room there.

No, the kernel code does what it does - user space does not influence this.

    > > how can software create nodes for a specific device?
    > 
    > You do not mean using mknod?

    I mean via mknod, e.g. if the user has a major/minor number,
    how should it be converted to a dev_t number?

The proper way is using the makedev macro in <sys/sysmacros.h>.
But in times of change you have to do everything by hand.
glibc still has to be updated.
(Steal the MKDEV macro from the kernel setup.)

Since new dev_t is compatible with old dev_t you need not
recompile or upgrade glibc or so, unless you actually want
to use more than 16 bits.

Andries

Re: major/minor split

[Andries.Brouwer]

> 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

Re: major/minor split

[Roman Zippel]

Hi,

On Wed, 19 Mar 2003 Andries.Brouwer@cwi.nl 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

Re: major/minor split

[Joel Becker]

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: joel.becker@oracle.com
Phone: (650) 506-8127

Re: major/minor split

[Joel Becker]

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: joel.becker@oracle.com
Phone: (650) 506-8127