From owner-freebsd-current Tue Apr 25 13:45:37 2000 Delivered-To: freebsd-current@freebsd.org Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by hub.freebsd.org (Postfix) with ESMTP id C1E0E37BD9D for ; Tue, 25 Apr 2000 13:45:30 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 12kCCu-000MNc-0B; Tue, 25 Apr 2000 20:45:20 +0000 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id VAA26414; Tue, 25 Apr 2000 21:45:13 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Tue, 25 Apr 2000 21:50:25 +0100 (BST) From: Doug Rabson To: Jake Burkholder Cc: Bruce Evans , Boris Popov , freebsd-current@freebsd.org Subject: Re: SMP changes and breaking kld object module compatibility In-Reply-To: <20000425160340.AE322BCA7@io.yi.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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