On Thu, 23 Sep 1999, der Mouse wrote:

> >   * It is a bit unclear when wedge info is destroyed.  Must this be
> >     done explicitely (per disk device, per wedge)?  Will media change
> >     be detected by the wedge driver?
> 
> It seems to me that a wedge device can be destroyed in two ways:
> 
> + Explicitly, as by wedgeconfig when run to repartition a disk.
> 
> + Implicitly, by destroying the real device underlying it (removing a
>    PCMCIA card or scsictl detach - if scsictl detach ever makes it in).

or detecting removable media has changed. :-)

> >   * We have to figure out a naming [scheme].  [...]  Whatever, I
> >     personally think that there must be a link between the
> >     <driver><instance><partition> (ie. sd1a) and the wedge name.
> 
> I'm not entirely sure the wedges have to have names in their own right,
> except in the sense that they have to have some kind of namespace in
> order for wedgeconfig to manipulate them.  I'm not convinced they need
> to exist in /dev, for example.

I agree. It could be nice (especially for partitions which have names),
but not necesasry.

> [Bill Studenmund]
> 
> > [A] couple of people (myself included) really don't like the idea [of
> > having the bootblocks pass in wedge info as I described above] as we
> > then need a daemon to fire up in single user in order to be able to
> > fsck more than the root filesystem.
> 
> Not necessarily a daemon; I see no reason why wedgeconfig couldn't run
> once, load its info into the wedge driver, and then go away.

That would work too. The only reason I suggested a daemon was that when
new media are detected, they get partitioned automagically.

> Admittedly, to people used to partitioning being entirely in-kernel,
> this will be a potentially nasty shock.  If it's not too much pain, I
> think Bill is right (in text I snipped); it would be good to be able to
> compile support for one or more partitioning schemes into the kernel.
> 
> > All we really need to do is delete readdisklabel and setdisklabel as
> > MD routines and totally kill writedisklabel (as userland tools do
> > this now).  We then make readdisklabel and setdisklabel the front
> > ends to the wedge system.  We can change the names to remove
> > disklabel if we wish. :-)
> 
> This *does* require a userland daemon.  It also sticks with making

How does this require a userland daemon? I was talking in terms of a
libwedge in the kernel which would respond to readdisklabel calls by
seeing if it can figure out what's on the disk. A daemon would only be
needed if we wanted automagic disklabel fixup.

> wedges part of the disk drivers, rather than devices in their own
> right, and thus runs into the raw-partition question.  I don't see
> what's wrong with giving the wedge devices their own major number; it
> makes sub-partitioning a whole lot simpler, completely nukes the
> question of how many partitions a device can be shattered into, and
> just generally simplifies the conceptual framework.

That's why I mentioned maintaining the unit/partition split in my note.
:-)

The big problem I see with having wedges fit into their own major number
is how do we preserve permissions across boot? Right now, we preserve
permissions by tying them to the indoe for a given name & major & minor #.
This method depends on the minor numbers (well the major ones too) staying
the same between boots.

I don't see how this is very feasable with wedges getting their own major
number. Because the minor number of a wedge will depend on when it is
discovered.

Say I have a zip disk at sd2 and a fixed disk at sd3, wired down in the
kernel config so that they don't move around. Consider what happens when
the wedge configurer comes along. It'll try sd2, then sd3. If sd2 is
on-line (media in it), it'll find all of the wedges on there. If it's not,
it won't. Then it will find all of the wedges on sd3.

So the minor #'s of sd3's wedges are now dependent on the presence or
absence of sd2's media.

The only way to avoid disaster is to have a fully dynamic devfs which
preserves permissions (and somehow rememberes the permissions are
assosiated with what). While such a thing is doable, if we give wedges
compact minor numbers, we'll need that devfs to get wedges.

That's a lot more work. :-)

My recomended solution is to just allocate 64 wedges/partitions per
device. Then as long as the drives are detected the same (and you're
supposed to wire things down which'd do this!), the minor #'s and the
permissions will be stable.

Given that I don't see much difference between 64 & 63 wedges, (like 1.5%
or so), make one of these 64 the whole-disk partition, and we don't need
a major # for physical drives and another for wedges. :-)

> Of course, most of these decisions will end up being made in favor of
> the choice preferred by whoever sits down and implements something. :)

Which is one reason I really like what Leo's been proposing. It moves us
in the direction of the wedge proposal in a reasonable step. :-) I think
it can get us the code cleanup & flexability of the wedge proposal in
short order. :-)

Take care,

Bill