kobj multiple inheritance

[Justin T. Gibbs]

> On Mon, 2003-09-22 at 20:50, Justin T. Gibbs wrote:
>> > I believe that I have the kobj multiple inheritance changes about ready
>> > for committing now. I have locked up the class handling in kobj and I've
>> > re-done the method dispatch so that it is MP-safe without needing locks
>> > (I would appreciate a close look at that part by another pair of eyes).
>> 
>> I've only just glanced at these patches, but I don't see how the
>> method cache is now MP safe.  Aren't you still vulnerable to a cache
>> collision from two different threads performing an operation on the
>> same class?
> 
> Thats the cunning part :-). The key is that the cache entries now point
> directly at the method structures instead of being copies of the
> structure. The main race condition theoretically present in the old code
> was that one thread could read a cache entry part way through that entry
> being updated by another thread. Since the cache entries are now simple
> pointers, that can't happen.

The code assumes that pointer accesses are atomic, which I didn't
think was guaranteed on all machines we support.  That's why I didn't
think it was safe.

>> I still believe that the concept of inherited interfaces is better
>> way to achieve multiple inheritance.  The methods I may want to
>> inherit need not be associated with what we currently call a device
>> class.  The nice thing about your approach is that it doesn't require
>> a massive rototilling of the drivers, but I fear it doesn't go far
>> enough toward providing flexible inheritence.
> 
> It was the mass rototilling which I wanted to avoid. It still seems like
> a pretty good thing to maintain some kind of API compatibility between
> FreeBSD 4, 5 and 6 and this method can support that. Your original
> scheme was 'single inheritance of multiple interfaces'. This patch can
> support that since you can derive from as many base classes as you like
> - each base class will be looked at if the previous class doesn't find a
> match.

There were quite a few differences:

1) Inheritence was not limited to only inheriting from a base interface.
   The method lookup traversed all the way to the root.

2) Default methods were removed and classes were forced to explicitly
   list supported interfaces.  I found this to be much less confusing.

3) Short-hand for inheriting all of the interfaces of a "parent class"
   were provided.  This just meant having the ability to list classes
   to inherit from so that the kobj class compiling code could iterate
   through all the interfaces of specified classes.

4) The method cache was removed in favor of a direct indexing into
   the interface's static method table.  Interface lookup was explicit,
   the hope being that one interface lookup could be amortized over
   multiple method calls.  This would allow using kobj interfaces
   for more heavy weight tasks such as exporting the correct XPT
   interface in CAM to low-level drivers (FC, SPI, SATA, SAS, etc).

5) I also planned to add a way to do "super" invocations.  This would
   cut down on lots of the bloat in things like cardbus.

The goal was to be able to do things like, using cardbus as an example,
inheret all of the interfaces of PCI adding in the CIS parsing interface
shared with pccard.  CIS parsing is just a list of methods that doesn't
make sense to be a "driver class" on its own.

I guess I have bigger dreams than most for how to use newbus...

Do you also have a proposal for handling ivar in the multiple-inheritance
scheme?  This is required to make multiple inheritance really useful.

--
Justin