[ On Mon, October 5, 1998 at 11:04:00 (-0700), Bill Studenmund wrote: ]
> Subject: Re: Another changer, another changer problem
>
> Why are we transitioning to 22-partition diskabels? That limit only
> applies to the *BSD label. MacOS-based labels can have any number of
> drives. In fact, we could have the pathelogical case of someone having 64
> partitions! Also, w/ MBR disklabels, we could get more than 22 partitions
> on a drive (if you have multiple OS's and each one has support for lots of
> partitions).
> 
> :-)

I'm sure glad that smiley is there Bill, but not so glad as I suspect
some other folks are!  ;-)

Sure, it would be cool to have an operating system that you could plug
any old disk into and be able to read the data from it.  That's sort of
where you could go if you added native fdisk support not only to the
i386 kernel, but to all of them.  I could then take a Linux/OS2/NT disk
and mount all the partitions from it on my sparcstation.

I agree though that all that bloat shouldn't be in every kernel.  I just
think it would be nice if you could get that code in there when you want
it.  Yes, one can use user-land tools that access the raw disk, and in
theory one could even convert something like mtools into a user-land
loopback filesystem.....  That might be better, actually, *except* on
the native platform (eg. FDISK labels should be in i386, and maybe MacOS
labels should be in mac68k, etc. -- even NetBSD/sparc *could* require
layering with native Sun labels and put the NetBSD label inside a
V_UNASSIGNED partition ;-).

While we're blue-skying about disk labels, I'd like to extend the disk
label and partition label with a few more fields, and that'll likely
reduce the MAXMAXPARTITIONS from 22 back down to 16 or so anyway....

0.25 ;-)

-- 
							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>