OK. I obviously asked slightly the wrong question
as I was talking about a theoretical case and chose
badly.
What I meant was 'Wouldn't it be better to use some form of
static identifier / volume serial / MAC address / whatever, which
/dev/[device-type]/[ID] exactly identifies, and continues to
identify, even across config changes, than (a) go look
for these ID's, then (b) sequence them in number disk0..N so
that if one is removed, all the rest of them shuffle down'.
IE isn't the point being argued here: 'don't identify
devices by major/minor device number pairs chosen on
a rather arbitrary and wasteful basis which describes how
the given device is physically connected' and not 'the
devices shall be dynamically ordered 0..N and rely
on the order of detection, and the number of
other devices, to determine their numbering'.
As has been pointed out elsewhere, if you expose
/dev/disk/0/serial-number and/or
/dev/disk/0/interface/scsi/ whatever, in a
format trivially readable by a script, the problem
largely goes away (+/- a linear search). However,
if you don't at least try to keep (say) disk
names static across reboot with trivial
reconfig change (like inserting a PCMCIA
flash card), I can see people are going to
need to rewrite stuff like mount to look at
(say) an fstab where the first field is
not /dev/hda0, it is something which identifies
a disk beyond /dev/disk/0 and actually goes looks
at the tree under that for some form of serial
number (or whatever), or mount -a will produce
surprising results (for instance there's no
reason a PCMCIA flash card might not be
detected before a PCMCIA HD). I understood 2.4
was meant to be pretty static in terms of
external interface.
-- Alex Bligh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/