VFS: C99 sparse format for struct vfsops

[Doug Rabson]

On Tuesday 03 June 2003 12:00 am, Paul Richards wrote:
> On Tue, 2003-06-03 at 23:09, M. Warner Losh wrote:
> > In message: <1054590840.1641.12.camel at cf.freebsd-services.com>
> >
> >             Paul Richards <paul at freebsd-services.com> writes:
> > : The possible methods available in an interface are fixed, they're
> > : defined in the .m files.
> >
> > No it isn't.  One can add additional interfaces at any time without
> > breaking binary compatibility, so you don't know, a priori, the
> > number of methods in a given interface when you build a client of
> > that interface.
>
> I don't think that's true.
>
> The interface is defined in the .m file and it's created using
> makeobjs. You can't do that at runtime because it creates the
> kobj_desc struct that uniquely represents the existence of that
> method globally for the whole of the kobj subsystem. The set of all
> kobj_desc defines all possible methods that can be implemented by an
> object, and yes you can extend that interface later and previously
> built modules will still work because they only implement a subset of
> those possible methods, but the set of all methods that can exist is
> determined at compile time from the interface definitions
>
> A class is then defined which specifies the set of methods that
> objects instantiated into that class *can* implement (but are note
> required to). The set of methods in a class is also fixed, since it's
> basically the method table plus some class fields and the method
> table is created at compile time. Again though, if you later extend
> the class older compiled modules will still work because if the
> method doesn't exist in that older module the default from the
> kobj_desc will be used or the kobj_error_method will be called (which
> is safe).
>
> So yes you can extend the interface and the class and keep backwards
> compatibility but that all happens at compile time, and therefore at
> runtime when the object is instantiated you know the maximum number
> of methods that the object can possibly call.

It is true, I'm afraid. A class is can implement any number of 
interfaces so knowing the compile-time size of an interface doesn't 
help you reserve space for a class. The system is intended to have a 
robust ABI so that e.g. a class implementing an interface can be used 
safely by a kernel in which new methods have been added to that 
interface.

The class is a concrete definition of a set of methods (at this level, 
the interfaces are mostly ignored). Objects instantiated in that class 
use exactly that set of methods, no more, no less. There is no choice 
involved. You appear to be confusing class and interface here.

This incarnation of kobj uses a smallish fixed-size method dispatch 
table, with hashing. A previous version (embedded into 4.x's newbus) 
allocated space in the method dispatch table for every interface which 
was currently resident in the kernel. This was fine when the expected 
number of interfaces was small but as the number of interfaces 
increases, the wasted space per-class increases unacceptably. This is 
the sole reason for changing the method-dispatch algorithm for kobj.

The only valid objection to kobj at this point is that resolving hash 
collisions is not SMP safe. I believe that this is a limitation which 
can be overcome without pessimising the dispatch mechanism.

Performance is not an issue. The performance of method dispatch in kobj 
is very slightly slower than a vtable-style array of function pointers 
but the difference is barely measurable. Given the behaviour of modern 
caches, it is possible to make nearly as many kobj method calls per 
second as normal function calls.

-- 
Doug Rabson				Mail:  dfr at nlsystems.com
					Phone: +44 20 8348 6160