On Fri, 24 Sep 1999, Frank van der Linden wrote: 

> If you want to have all initial wedges configured in single user
> mode, you end up putting knowledge about all types of native
> partitioning in the kernel, which is exactly the opposite of
> one of the main points of the wedges proposal.

This point of the initial proposal is the most controvertial one, I think.
:-) Controvertial in that many folks don't like it.

Why do we want to move the partitioning out of the kernel? What do we
gain? I'm not saying we'd gain nothing, just asking what we'd gain. ;-)

More importantly, is removing disklabel understanding out of the kenrel
the only way to achieve what we want?

If moving disklabel understanding out of the kernel is what we want to
achieve, well then there's now way around it, and we're talking about
something which many people don't like. Given that some people think it'd
be a step towards instability, folks will get riled up. :-)

If however we want to get rid of the situation where there's disklabel
understanding code in each port's MD section, that this code is different
for each port, and that this code is different from what is in the boot
block code, and that code is different from what's in userland, things are
different. There's another way.

The reason I babbled about a libwedge in the kernel is that with it we'd
gain the above advantages by taking a step everyone likes without taking a
step over which there's disagreement. While the kernel would still have
the ability to read different disklabel formats (the list of which is
generated at config time), it would be using the same code as the boot
blocks. The code pseudo-duplication we have now (almost the same code in
different places) would be gone. :-)

> The userspace handling doesn't need to be a "daemon" at all, I see
> very little reason for it to be a daemon. I'm also not sure what
> keeping the old *disklabel interface would gain you. It should
> probably go into libcompat, but all tools should use the new
> interface.

About a daemon: you're right that there should be a wedgeconfig command.
I've spoken of a daemon as it'd be nice to support removabel media - you
shove in a new disk in a zip dirve, or add a disk to your fiber fabric,
and the right thing happens. But a daemon could fork off the wedgeconfig
program (seperating the two).

About keeping the disklabel interface: I'm assuming that we're going to
keep the unit/partition split to device minor numbers (see my post
yesterday about the problem with just throwing wedges into their own major
# with minor numbers dictated by allocation history). Given that, we need
a table to map minor numbers to offset/size pairs. That functionality can
be achived by what Leo was calling the in-core disklabel. We can call it
something else, but either way it's a table for partition to offset/size
mapping. :-) So why not re-use the existing interface (well with throwing
out the ability to write disklabel since that's now exclusivly for
userland). ??

Take care,

Bill