Subject: Re: Thoughts about wedges
To: Leo Weppelman <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 09/24/1999 13:25:28
On Fri, 24 Sep 1999, Leo Weppelman wrote:
> On Thu, Sep 23, 1999 at 12:22:32PM -0700, Bill Studenmund wrote:
> > On Thu, 23 Sep 1999, Leo Weppelman wrote:
> [ ... ]
> > It would be compat_14 if we depreciated the ioctl's.. but see below.
> Sorry, I should have been clearer. With 'sdcompat' I meant the sdcompat
> device from Charles' wedge proposal.
Ahh, that would be a little different. The issue of preserving permissions
across reboots wasn't touched in the initial wedge discussion. Doing that
right raises the bar on the implimentation. I think it raises the bar high
enough that we'll be waiting for it for another 18 months. :-)
Given that, I think the unit/partition split (where the minor number gives
us unit and partition, as opposed to being an offset into a large table)
si the way to go. That's basically what you'd done with the in-core
disklabel. Thus we don't really need the sdcmpat driver spoken of before.
We would need a way to map old major partitions into new ones, but a table
of 16 integers mapping to new partition #'s will do that. :-)
> > The idea is that the userland version would know how to read all of the
> > partition types we know, and the kernel & boot blocks would know of a more
> > limited set of types.
> I like to point out that Wolfgang Solfrank had a good point on this a while
> ago, in that it would probably be best to create one program per partition
> type to read/write the partition info. The argumentation was that there are
> quite a lot of scemes that all have there weird edges. Putting this in one
> program would probably create a hard to maintain program.
> I _think_ the complexity problem most hits the creation/change of the labels.
> The reading & interpretation is probably a lot simpler.
I've deliberatly stayed away from saying what userland will do. I think
you're right that having individual programs to edit different disklabel
formats is best. But it'd probably be nice to have just one which would do
the reading the labels and load the in-kernel data. :-)