mknod64(1)

mknod64(1)

[Robert Love]

So I wrote a mknod64(1) tool, so we can play with 64-bit device
numbers.  It is available at:

	ftp://ftp.kernel.org/pub/linux/kernel/people/rml/mknod64

for testing.  And that is really its whole purpose because I see no
reason why the mknod in coreutils will not eventually support
mknod64(2).

But for now this version works and supports the 64-bit dev_t with a
32:32 split.  It is also identical in functionality to mknod(1), except
it does not support an initial mode other than the default (i.e., no
--mode option).

Installation is simple but RPM packages are also available.

Usage is the same as mknod, except you may specify a 32-bit value for
the major and the minor device number.

This currently requires 2.5.67-mm4, but I suspect the 64-bit dev_t work
will eventually make its way into Linus's tree.

Note that most utilities cannot see the 64-bit device numbers, i.e.
ls(1) only displays 8-bits of each.  You can do a homemade stat64() or
just trust the code.

With the above kernel and this utility, you can play with 64-bit device
numbers.  Enjoy.

	Robert Love

Re: mknod64(1)

[H. Peter Anvin]

Followup to:  <1050700383.745.48.camel@localhost>
By author:    Robert Love <rml@tech9.net>
In newsgroup: linux.dev.kernel
>
> So I wrote a mknod64(1) tool, so we can play with 64-bit device
> numbers.  It is available at:
> 
> 	ftp://ftp.kernel.org/pub/linux/kernel/people/rml/mknod64
> 
> for testing.  And that is really its whole purpose because I see no
> reason why the mknod in coreutils will not eventually support
> mknod64(2).
> 

Well, actually, once glibc is updated to call SYS_mknod64 and have the
right MAJOR() and MINOR() macros, it shouldn't require any changes to
mknod(1).

What would probably be useful for mknod(1), if it doesn't already, is
to allow the major/minor to be specified in any of the standard bases,
i.e. using strtoul(...,...,0).

I belive HP/UX (which have had 32-bit minors for a long time) actually
had ls -l display hexadecimal minors.  I am not advocating that,
however, it probably would break too many scripts.

	-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: mknod64(1)

[Robert Love]

On Fri, 2003-04-18 at 17:24, H. Peter Anvin wrote:

> Well, actually, once glibc is updated to call SYS_mknod64 and have the
> right MAJOR() and MINOR() macros, it shouldn't require any changes to
> mknod(1).

Agreed.  Assuming mknod(1) is dev_t-clean, this is obsolete as soon as
glibc is updated for 64-bit dev_t.  Until then, this is available and
easy and works.

> What would probably be useful for mknod(1), if it doesn't already, is
> to allow the major/minor to be specified in any of the standard bases,
> i.e. using strtoul(...,...,0).

mknod(1) does not, I think.  Actually, maybe it does... it uses some
coreutils wrapper.

But my mknod64(1) certainly does :)

Hex, decimal, and binary should all work.

	Robert Love

Re: mknod64(1)

[Andreas Schwab]

Robert Love <rml@tech9.net> writes:

|> On Fri, 2003-04-18 at 17:24, H. Peter Anvin wrote:
|> 
|> > What would probably be useful for mknod(1), if it doesn't already, is
|> > to allow the major/minor to be specified in any of the standard bases,
|> > i.e. using strtoul(...,...,0).
|> 
|> mknod(1) does not, I think.  Actually, maybe it does... it uses some
|> coreutils wrapper.

The wrapper is essentially calling strtol in the end, so yes, coreutils'
mknod does support the standard bases.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."