Subject: Re: Why not change disk naming?
To: None <email@example.com>
From: Kip Rugger <firstname.lastname@example.org>
Date: 12/28/2001 15:53:17
>Yes, I know that you only suggested being like FreeBSD. But, for
>one thing, I don't think their system is particularly more useful
>than ours and, for a second thing, I think if you're going to go for
>more utility, you might as well go all the way.
>Note that just making this "like FreeBSD" is somewhat distasteful to
>those of us not using PC hardware. The current system makes for
>short-to-type and perfectly clear ames on most of our ports
>(certainly most that I've used). And there're none of these stupid
>differences between disk labels and MBR labels. That's a
>PC-hardware-sucks problem, not a software problem.
>(By which I mean, I'd be kind of irked if my user experience on
>macppc, mac68k, and sparc was changed just to satisfy a few people
I am totally in accord with these sentiments. My `universe' includes
macppc *AND* the dreaded i386. I don't want the macppc port corrupted
by i386 `fixes'. Or vice versa.
As author of PR 7950, dated Jul 1999, I supplied a patch to have
the kernel construct a BSD disklabel from the MBR&c stuff, *in the
absence of a NetBSD label*. What the patch effectively said was:
``don't ever run disklabel(1), let the kernel build it every
time you boot from an MBR disk on i386. Let it find your extended
or changed partitions, just as *choke* DOS would.''
In other words, the concept is that the MBR stuff is authoritative
in the i386 world *in absence of a BSD label*, and that the BSD
label should be constructed at boot time. Stated a bit differently,
you shouldn't have to supply redundant, and possibly conflicting,
information for the partition table. Just use the MBR on i386. Period.