Subject: Re: dev_t changes & partitions
To: Wolfgang Solfrank <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
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
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.