Re: VFS: C99 sparse format for struct vfsops

On Wed, 2003-06-04 at 14:16, Paul Richards wrote:
> On Wed, Jun 04, 2003 at 01:33:46PM +0100, Doug Rabson wrote:
> 
> > Interfaces actually can be added at runtime. Existing objects (i.e.
> > objects instantiated before the new interface was added) will continue
> > to work as before. If methods from the new interface are called on old
> > objects, the default method will be called.
> 
> How can you add an interface at runtime?

By loading a kernel module. If I load e.g. the agp kernel module, I add
the agp_if interface to the kernel.

> 
> All of this runtime activity is theoretically possible, i.e. all
> these structures can be messed around with to add methods to existing
> objects etc. but wasn't kobj supposed to provide an OO type
> abstraction and therefore the interfaces and classes are determined
> at compile time.
> 
> I'm not aware of any actual code that changes interfaces or classes
> at runtime and if we added that functionality then I think it would
> break the abstraction and complicate the usage of kobj for no real
> gain.
> 
> Coming back to the central point, I don't understand why we need
> a cache at all. I don't see the reason for having to support the
> dispatching of anything other than the methods in the class that
> the object was instantiated into, so that means a relatively small
> fixed size method dispatch table.
> 
> The only argument for that not working is if the class gets extended
> after the object is created but I'm not convinced yet that that's
> something to worry about in practice at least at the moment since we
> don't extend classes anywhere.
> 
> Even if we added code to make that possible at runtime it would be
> simple enough to get a "miss" when looking that method up in older
> objects and to realloc the method table in the object to accomodate
> the new methods. Extending the class is something that is likely
> to be so rare that some performance penalty should that happen
> would be palatable.

The code which is doing the method dispatch has no real idea what
methods (or what interfaces for that matter) that the object's class
implements. You can't use the classes method table layout for the ops
table since the caller has no way of knowing that layout (and the layout
will be different for almost every class in the system).

One possible way of making this slightly simpler might be to make the
class point at a table indexed by interface ID, each entry of which is a
table indexed by a method ID from that interface. This sounds fine in
theory but in practice, it would end up slower due to the two memory
accesses.