[ On Sun, October 4, 1998 at 20:47:29 (-0700), Todd Whitesel wrote: ]
> Subject: Re: Another changer, another changer problem
>
> [ On Mon, October 5, 1998 at 12:53:40 (+1000), Robert Elz wrote: ]
> > 
> >     [ On Sun, October 4, 1998 at 18:49:04 (-0700), Curt Sampson wrote: ]
> >      
> >     Once again, look at the code. We do provide that minor number; it's
> >     the one attached to /dev/xdNc. That partition need not start at
> >     zero, and it doesn't matter what's in the disklabel in memory or
> >     on the disk. The start/end data for that partition are ignored.

[ Curt seems to miss my point entirely, again.... ]

> > That's fine - but it is a waste of a partition label on the disk
> > that could be used for something more productive.
> 
> Unfortunately yes it is, but to reuse that entry means a definite change in
> the interpretation of disklabels, and that creates a format transition which
> should not be taken lightly.

It's way more than just a "waste of a partition label" (though in the
world 23GB disks and only 8 partitions per disk it is most certainly
that too).  For me it's more an issue of consistency and "doing what the
user means".  The real black and ugly magic is throwing away anything
the user may have stuffed in the 'c' or 'd' partition.

Indeed it is not a change to be made lightly.  However that's what
version numbers on data structures are helpful for.  With proper
planning (i.e. designing and coding drivers and tools so that they can
deal with both new and old formats, and provide mechanisms to convert
between formats) such transitions can in the end appear to be trivial
and indeed be painless.

> Perhaps we could do it as part of a transition to 22-partition disklabels
> across the board, with both 'c' and 'd' reserved for driver internal purposes.
> (I have my own agenda here; someday I want to read my i386 volumes and their
> DOS data on my arm32, so I will keep stumping for an acceptable MI
> implementation of the i386's 'd' partition concept.)

The mere concept of reserving *any* part of a limited resource data
structure is completely revolting to me.  If we want "magic" then we
should do it in the minor number mapping, *not* by ignoring entries in
data structures created by administrators to define local allocation of
their resources.
 
> I personally would not mind something like:
> 
>  	part = DISKPART(dev);
> 	switch (part) {
> 		case 'a' - 'a':
> 			/* access via disklabel[0] */
> 			break;
> 		case 'b' - 'a':
> 			/* access via disklabel[1] */
> 			break;
> 		case 'c' - 'a':
> 			/* set up to access netbsd area, whatever that means */
> 			break;
> 		case 'd' - 'a':
> 			/* set up to access whole disk, no matter what */
> 			break;
> 		default:
> 			/* access via disklabel[part-2] */
> 			break;
> 	}
> 
> One could easily argue that this is pretty inelegant, but it's worth it to me
> because it buys me a lot!!

That's just as ugly and messy as putting support for fdisk into the i386
kernel and it still relies on people getting things set up consistently
between two disparate tables.  IMNSHO it's far *safer* to force the code
to obey the table definitions in their proper hierarchy.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>