RFC: adding 'proxy' nodes to provider ports (with patch)

[Pawel Jakub Dawidek]

On Sat, Mar 21, 2009 at 12:34:37AM +0100, Ivan Voras wrote:
> Not only with naming and device creation - the proxy classes cannot be
> "normal" classes because it's common that "normal" classes do a lot of
> initialization in .taste. (i.e. there at least needs to be a flag for
> proxy classes)

There are many leaf GEOM classes where taste is never used and also
non-leaf classes that don't use tasting (like gbde or geli). Those
aren't special GEOM classes in any way.

I recommend reading phk's GEOM tutorial from BSDCon 2003. You can find
an interesting slide which seems to sum up this thread quite nicely:

	Special GEOM classes.
	---------------------

	- There are no special GEOM classes.

I wonder if phk changed his opinion over time. :)

Maybe instead of adding special providers and GEOM classes, the
infrastructure should be extended in some way, so that we won't use
provider term to describe something that isn't really a regular GEOM
provider.

On the other hand disk scheduler provides kind of transformation, the
only real problem is usability - doing it in the same way as the other
GEOM classes will make it much more problematic to use. Current patch
makes it much easier to use, but violates infrastructure.

Another thing came to my mind. Currently GEOM does nothing to prevent
situation where there are two GEOM providers using the same name - we
just end up with two /dev/foo entires which is a bit surprising.  I was
wondering if we couldn't clean this up (at least partially) and
implement insert/remove functionality for GEOM in one go. For example we
have /dev/ad0 provider created by the DISK class. We create another
provider /dev/ad0 of SCHED class. Then we insert SCHED:/dev/ad0 on top
of DISK:/dev/ad0. GEOM will reconnect all existing consumers from
DISK:/dev/ad0 to SCHED:/dev/ad0 and connect SCHED consumer to
DISK:/dev/ad0. Also, GEOM will show only one /dev/ad0 entry in /dev/ -
the one which comes from a geom with higher rank count.

Now whoever wants to open /dev/ad0 will end up opening SCHED:/dev/ad0
(so there won't be a problem with new consumers).

Of course providers that come from geoms with the same rank count would
still be a problem, but... Also instead of rank count we could only
allow connected providers to cover their children.

What do you guys think?

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090321/454573bd/attachment.pgp