Leo Weppelman <leo@wau.mis.ah.nl> writes:
> Maybe a better approach is decoupling the kernel-disklabel from the
> userland-disklabel?

That's close to what I think i suggested, but not quite as useful.


> What I mean is:
>     - export a disklabel definition to userland with 64 partitions

Sure...

>     - provide functions in the kernel to copy between the kernel and
>       userland definitions.

uh, i don't think that's quite right.

for the most part, even in the kernel, you want to use the "large # of
partitions" disklabel.  This is true at least because of the existence
of (programs like) "mbrlabel" which manipulate the in-core label
without the expectation that it'll ever be written back to disk.  For
them, it can be valuable to provide more partitions throughout the MI
code.

There's the minor hitch that not all of those partitions (the ones >
MAXPARTITIONS) will be accessible on ports with small maxpartitions,
but I think that's OK.  (At least people can know what they're
missing.  8-)

The important thing to do, in my opinion, is decouple the on-disk
format from the MI-kernel/userland format.  You have to do this
anyway, because the MI kernel and userland needs to be able to
represent many formats other than the native 'struct disklabel'
format.  (MBRs, old sun disklabel, Mac and other partition tables,
etc.)

A good start on the conversion functions (setdisklabel,
checkdisklabel) are already there.


> To be clear: This still requires the getmaxpartitions() use, since it
> doesn't make sense to pass 40 partitions to a kernel supporting only 8
> of them.

depends on what you mean by 'pass'.  The cost (time) of passing the
functions into the kernel is pretty much irrelevant.  To a
zeroth-order approximation, disklabels are never set or read by user
programs.  8-)

getmaxpartitions() (and other good sanity checks) are still quite --
perhaps more -- important so that programs like disklabel(8) can
provide users better feedback about what they're doing wrong when
creating disklabels for their systems.  Right now those sanity checks
and diagnostics... aren't so great, in my opinion.



There might be some desire to optimize space usage for some ports by
making the number of partitions in kernel different from the user-land
max as well as different from the on-disk max, but that's an optimization.



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.