Subject: Re: dev_t changes & partitions
To: Wolfgang Solfrank <>
From: Bill Studenmund <>
List: tech-kern
Date: 01/16/1998 10:27:29
On Fri, 16 Jan 1998, Wolfgang Solfrank wrote:

> It will ignore the MBR partitions of the other OSs.  Do you really suggest
> that we implement the disklabel scheme of every other OS in the world?
> _In the kernel_?

As Ted mentioned, we don't have to support EVERY OS in the world, just the
ones we want to. I'd envision most of this support being kernel-compile
options. So if someone wants to add support for Dr. Dobbs' Donkey-Kong DOS
(and they conditionalize it), so be it. It won't have to be in your (or my
:-) kernels. Maybe also letting a (super)user program come along and
twiddle with things, so the kernel's abilitys stay slim but we can plump
up an external program.

> IMHO our disklabel should allow for a large enough number of partitions, and
> the user should enter any partition he wants to access into our disklabel
> (as is already current practice).  Probably there should be some utility
> per foreign disklabel that assists him in the process.  It probably would
> also be a good idea if the kernel would allow for the user to only set the
> incore disklabel.  Combined with the previous conversion utility this should
> do everything that one would want, doesn't it?

Yes, except that the utility has to be re-run after changing things. For
the "popular" OS's, like out cousin BSD's and for Linux, it'd be nice if
it just happens automatically.

> > I liked the idea of making slices vnodes on the fly. My idea is, for each
> _If_ by this you are talking about the generation of a fake disklabel
> from the MBR records (including MBR records in extended partitions) as is
> done in the powerpc port, this code is by yours truely.  And this is kludgy
> enough to not make me want to add support for yet more random disklabel stuff.

I haven't looked at that code. But my main thought with the "slicing
layer" is that we have the real disklabel which is on disk, the disklabel
for the "un-sliced" unit, and a TOTALLY fake disklabel for the "sliced"

> What about extended partitions?  If you don't know, this is a MBR partition
> that itself has an MBR and further partitions.  I'm not sure with how this
> works in x86 machines, but with powerpcs you can have these arbitrarily
> stacked.

I didn't know about that. Ick. Probably the best thing'd be to have the
kernel make a good first pass (like go one layer into the extended
partitions) and leave the rest to a userland program.

Take care,