mknod64(1)
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
Followup to: <1050700383.745.48.camel@localhost> By author: Robert Love <[email protected]> In newsgroup: linux.dev.kernel
Quoted 10 lines
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
Signature · 3 lines
<[email protected]> at work, <[email protected]> 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
Quoted 3 lines · H. Peter Anvin
Well, actually, once glibc is updated to call
SYS_mknod64and have the rightMAJOR()andMINOR()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.
Quoted 3 lines
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
Robert Love <[email protected]> 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.
Signature · 4 lines
Andreas Schwab, SuSE Labs, [email protected] 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."