From owner-freebsd-hackers  Fri Dec 19 06:23:57 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id GAA19938
          for hackers-outgoing; Fri, 19 Dec 1997 06:23:57 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from word.smith.net.au (ppp6.portal.net.au [202.12.71.106])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA19925
          for <freebsd-hackers@FreeBSD.ORG>; Fri, 19 Dec 1997 06:23:45 -0800 (PST)
          (envelope-from mike@word.smith.net.au)
Received: from word (localhost [127.0.0.1])
	by word.smith.net.au (8.8.8/8.8.5) with ESMTP id AAA00414;
	Sat, 20 Dec 1997 00:47:34 +1030 (CST)
Message-Id: <199712191417.AAA00414@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Michael Hancock <michaelh@cet.co.jp>
cc: John-Mark Gurney <gurney_j@resnet.uoregon.edu>,
        freebsd-hackers@FreeBSD.ORG
Subject: Re: converting drivers to dynamic memory... 
In-reply-to: Your message of "Fri, 19 Dec 1997 16:18:42 +0900."
             <Pine.SV4.3.95.971219161236.5078F-100000@parkplace.cet.co.jp> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 20 Dec 1997 00:47:33 +1030
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > > Forget the btree model; it's not going to fly in the face of a direct 
> > > reference approach. 
...
> > when did I ever say that we should in the long run choose using a
> > btree over the "correct" way to do it??  I only said it would require
> 
> Hashing for example is very good in the kernel, even in cases where you
> think btrees would be better.  The reasoning is along the lines of what
> Koshy was talking about.  If you can abstract things well enough so that
> you can make a change later on very easily, by all means carry on. 
> Someone will find a use for your Btrees elsewhere most likely. 

... but of course dereferencing a pointer (hardly) requires any 
parallelisation.  Why go to all this complexity when all you are 
interesting in doing is taking an opaque token and obtaining the 
address of a (reasonably non-motile) structure?

Perhaps I'm missing something; let's take the opposite tack.  What 
advantages (in real terms) do we gain by storing the address of the 
control structure in some fashion and then requiring a token in order 
to obtain it?  Is this advantage significant in the face of the not 
insubstantial performance penalties?

mike