Re: Migrating to larger numbers

Albert D. Cahalan (acahalan@cs.uml.edu)
Thu, 10 Jun 1999 05:05:42 -0400 (EDT)


Kai Henningsen writes:
> acahalan@cs.uml.edu (Albert D. Cahalan) wrote on 09.06.99 in <199906090525.BAA05821@jupiter.cs.uml.edu>:

>> Trying to do dynamic device numbers and/or names with the current system
>> is a bad joke.
>
> I'm using that right now. Ok, so those numbers don't change all that
> often, but when they do, it still works.

I didn't say you couldn't find any hack at all. You found one in fact,
and it sure looks like a bad joke.

> scsidev can create aliases for all those scsi devices; specifically, it
> can create aliases depending on scsi id data (manufacturer, model, serial
> number). I use this and mount all my partitions (even swap) via those
> names.
>
> It works fine as long as the kernel doesn't renumber the disk holding the
> root and/or boot partition, because those happen before I get access. (And

Well, that sucks. Devfs doesn't have that problem.

> I could probably handle root from an initrd, but right now it doesn't seem
> worth the bother.)

Why such a bother? Devfs is easy to use, unlike your hack.

> All the other disks can be freely rearranged, and the machine will
> automatically mount the right partitions. (Now if I also had something to
> recognize renumbered partitions, like a file system uuid ... should be
> easy to add, anyway.)
>
> This setup is slightly complicated by the r/o root mount, but I solve this
> by allocating two small ram disks (on /tmp and /dev/scsi) the first time
> around, which get thrown away once they're no longer needed.

Arrrgh!!!

Can't you see all the contortions you are going through? If you need to
mount two small ram disks to deal with the r/o root mount, something is
very wrong. I'd say you have chosen an inappropriate solution.

Yes, your system does work. You found a way to avoid devfs, but you ended
up with something far more complicated and kludgy. Considering the problems
with your root filesystem, your system might even be less reliable.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/