Date: Thu, 18 Dec 1997 06:51:07 -0800 From: John-Mark Gurney <gurney_j@efn.org> To: Darren Reed <avalon@coombs.anu.edu.au> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: converting drivers to dynamic memory... Message-ID: <19971218065107.10999@hydrogen.nike.efn.org> In-Reply-To: <199712181431.GAA14258@resnet.uoregon.edu>; from Darren Reed on Fri, Dec 19, 1997 at 01:31:43AM %2B1100 References: <19971218053840.15389@hydrogen.nike.efn.org> <199712181431.GAA14258@resnet.uoregon.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Darren Reed scribbled this message on Dec 19:
> In some mail from John-Mark Gurney, sie said:
> >
> > > Hmmm. So how exactly does the B-tree solve the problem ? You're
> > > allocating
> > > the dynamic data and storing it on the B-Tree and then have to look
> > > it up by
> > > searching the B-tree ? Aren't there better ways of allocating data
> > > and then
> > > looking up where it is (what about asking the driver itself) ?
> >
> > correct.. this is EXACTLY what the code does.. the problem is that
> > right now the data is stored in a static table, because of this, you
> > can't just say, hey, I need another instance of you to attach to this
> > card... we could even go with a small array of pointers that gets
> > realloced/resized each time a driver gets attached... (which might be
> > better, I happen to have just finished testing the btree code, so that
> > influenced my choice.. :) )..
>
> Now I've got more clues so I can understand where you're going with all
> of this :)
>
> Well, FWIW, Solaris2 does the "extra pointer" thing in its DDI :)
>
> However, if you are using multiple instances, you do need to keep track
> of which is which (guess you could use B-Trees for this :) yourself.
>
> Their function call interface consists of over 120 functions which support
> using the extra pointer (they call their void * type dev_info_t).
yep, I think that would be a great addition... IMO, once devfs has
finally been completed, we will still need a minor number of the void *
(I happen to like the name dev_info_t), the minor so that we know what
part of the device driver we are accessing... else we would need to
allocate a bunch of small structs like:
struct {
int option;
struct devicedata data;
}
which would be really wasteful of precious memory resources...
> Hmmm, on second thoughts maybe instead of option 1 and option 2, option 2
> should be phase 1 and option 1 should be phase 2 ? :-)
I completely agree... I'll probably end up doing phase 1 of the project
myself, unless there are others who are willing to do the work.. and
if there are, I'll put together the frame work neccessary (basicly,
fix up the btree code, and do a driver as an example)...
--
John-Mark Gurney Modem/FAX: +1 541 683 6954
Cu Networking P.O. Box 5693, 97405
Live in Peace, destroy Micro$oft, support free software, run FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971218065107.10999>