UUIDs on drives

[Derek Broughton]

ghe wrote:

> (This is long, but hopefully the end.)

Not possible... :-)
> 
> Look. I think we're all saying pretty much the same thing, but, as
> someone has said, we're looking at the situation from different points
> of view and different layers of software/firmware.

OK, but you're looking at it from the _wrong_ point :-)  Seriously, the
whole point of software is to separate the user from the hardware by levels
of abstraction, and you are complaining that we're accomplishing that too
well.

> My own orientation is somewhat hardware-based. My first computer had no
> peripherals or drivers, so (with the help of a mentor who knew what he
> was doing) I built the controllers and wrote the drivers. So I tend to
> think of a disk drive (or whatever) as a collection of I/O addresses for
> however the CPU does its I/O.

And do you believe that we should be writing out to specific addresses on
the disk?  QED.

> If I install onto a disk in the leftmost SATA slot, there's a unique and
> unchanging I/O address associated with that disk (as long as it's in the
> same slot), and I see no reason why the ROM code and the boot loader
> should ever need to refer to it as anything else. 

Because they should never NEED to know that they're using the leftmost SATA
slot.  If my boot loader assumes my boot drive is in the leftmost SATA
slot, I can _never_ move it.  It shouldn't - and doesn't - care.

> I know it doesn't work this way now, and that's largely what I'm whining
> about.

What's more: it MUST not work this way.
 
> In my case, with Ubuntu dual booting on the Mac Pro,, udev apparently

No, udev did nothing of the sort.  udev acts _after_ the kernel.

> (hd0) was always the same because it was determined by the ROM code, but
> sda wasn't, so when (hd0) was hit to boot, it found and ran grub just
> fine. 

So?  If you'd just used UUID you wouldn't have had this issue.

> There are "udev rules" that could maintain consistency with all this,
> but the installer would have to write some, if a given disk is always to
> have the same label.

It shouldn't.  It's a basic principle of relational databases that keys
should not have semantic content.  That seems to be equally applicable to
the hardware database.

> And, as has been pointed out, the installer doesn't do that. It could,
> though. If creating fstab is part of its job, why shouldn't writing a
> few udev rules be, too?

Absolutely, it could.  BUT IT WOULD BE A BAD THING!  If you insist, you can
write those udev rules.  Please don't distribute them.

> udev's purpose of getting rid of redundant nodes in /dev 

I can't see that that was _ever_ udev's purpose.  If it was it got derailed
really quickly, as any udev tree has always been a whole lot bigger than
the pre-udev device tree, afaict.

> Since the node names in /dev are just strings, C's going to be referring
> to them with pointers anyway, so what's the disadvantage of calling
> things what they are: SCSIa, SATAa, SASa, IDEa, ATAPIa, FIREWIREa,
> IEEEa, USB_STICKa, PICTURE_FRAMEa, etc? 

The disadvantage is that I should never need to know _what_ sort of hardware
I'm using.  All I need to know about the hardware is whether it's removable
or not, and if removable, where it's plugged in.

> But UUID on top of udev on top of the kernel on top of the BIOS on top
> of the CPU's I/O... There's got to be an easier way to get to an I/O port.

Why?  You shouldn't normally want to get to an I/O port.

> But if I'm thinking something that isn't true or 
> doesn't make sense, I'd very much like to know about it.
 
Gee, I keep telling you that, but you don't seem to want to know about it...
-- 
derek