Date: Sat, 20 Dec 1997 00:47:33 +1030 From: Mike Smith <mike@smith.net.au> 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... Message-ID: <199712191417.AAA00414@word.smith.net.au> In-Reply-To: Your message of "Fri, 19 Dec 1997 16:18:42 %2B0900." <Pine.SV4.3.95.971219161236.5078F-100000@parkplace.cet.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712191417.AAA00414>