Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 25 Apr 2000 21:50:25 +0100 (BST)
From:      Doug Rabson <dfr@nlsystems.com>
To:        Jake Burkholder <jburkhol@home.com>
Cc:        Bruce Evans <bde@zeta.org.au>, Boris Popov <bp@butya.kz>, freebsd-current@freebsd.org
Subject:   Re: SMP changes and breaking kld object module compatibility 
Message-ID:  <Pine.BSF.4.21.0004252146030.79607-100000@salmon.nlsystems.com>
In-Reply-To: <20000425160340.AE322BCA7@io.yi.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 25 Apr 2000, Jake Burkholder wrote:

> > On Tue, 25 Apr 2000, Boris Popov wrote:
> > 
> > > 	simple_lock* functions has breakage too. They defined as macros
> > > for non-SMP case and as functions for SMP.
> > 
> > This currently apparently affects the following modules:
> > 
> >     ccd
> >     cd9660
> >     msdosfs
> >     nfs
> >     ntfs
> >     nwfs
> >     vinum
> > 
> > All of these functions reference simple_lock() if it is not defined away.
> > 
> > Bruce
> 
> Has anyone thought about using kobj(9) for this?
> 
> For example, it should be possible to make simple_lock and lockmgr locks
> safe for use from modules by introducing a lock_if.h, which has
> abstract version of all the lock routines.  A class would be compiled
> with null implementations for UP, or the 'lock'ed implementations for SMP.
> The old functions would call through an instance of that class, automagically
> finding the right method.  Eventually this could be a runtime abstraction,
> with both up and smp classes compiled into the kernel, and objects initialized 
> with the right method table at boot time.
> 
> I have diffs in the works if anyone is interested.

Its nice to see someone actually using kobj so soon. There is a possible
performance problem though - kobj method calls are roughly 20% slower than
direct function calls. Having said that, this isn't that slow - I timed a
method call to a two argument function at ~40ns on a 300MHz PII.

I could improve this for some applications (including this one) by
providing a mechanism for an application to cache the function pointer
returned by the method lookup.

-- 
Doug Rabson				Mail:  dfr@nlsystems.com
Nonlinear Systems Ltd.			Phone: +44 20 8442 9037




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0004252146030.79607-100000>