On Tue, 01 Jan 2013 13:50:07 -0500 (EST), Jonathan Nieder wrote:
>
> Technically the current code only makes sense for 5 hexdigits.
>
> After that, something more complicated could work:
>
> # 16 hexdigits: 0xMMMMMmmmmmmMMMmm
> devno=$(( 0x${1} ))
>
> major=$(( (($devno >> 8) & 0xfff) | (($devno >> 32) & ~0xfff) ))
> minor=$(( ($devno & 0xff) | (($devno >> 12) & 0xffffff00) ))
I'm not sure I follow this. But in any case, it's not worth doing.
The use of a hexadecimal number is largely a legacy case left over
from the pre-udev days; and as far as I know, lilo is the only boot
loader which still uses this method (for some cases only). If lilo
is configured as recommended for modern GNU/Linux distributions,
it specifies the root file system via a UUID or LABEL specification.
The current code works the way that lilo works, and I doubt that
the lilo code in question will ever change its algorithm. It currently
assumes that both the major and minor device numbers of the root file
system are less than or equal to 255, and that is what the parse_numeric
shell function in initramfs-tools assumes also. If those assumptions
ever become a problem, lilo will probably specify the root file system
in a different way rather than continuing to use a hexadecimal number.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/846143425.556937.1357180686930.javamail.r...@md01.wow.synacor.com
