Date: Thu, 18 Dec 1997 19:29:51 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: gurney_j@resnet.uoregon.edu Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: converting drivers to dynamic memory... Message-ID: <199712181929.MAA11029@usr05.primenet.com> In-Reply-To: <19971218035032.46460@hydrogen.nike.efn.org> from "John-Mark Gurney" at Dec 18, 97 03:50:32 am
next in thread | previous in thread | raw e-mail | index | archive | help
> There are two ways that we can fix this problem. The first (and > technically the best) is to be extend many of the calling functions > to pass around a void * pointer that will point to that devices > resources. Though this is technically best, it will require that > most major parts of the kernel be significantly changes. > > The second solution is to continue to use the major/minor code scheme, > but use a binary tree or a B-tree to obtain the private data. This > can cause a performance impact if we use if for things like the sio, > but this can be fixed by changing the interrupt interface. > > I think that we should go with the second solution as it will be > initalially easier to do. I have B-tree code already writen, (I was > writing it for another use in my bus/device code) which we could use > to access this information. (Some people will say, why not linked > lists, and then I will say, sio, I have 12 ports on my term server, > plus you get better data density) I think this will be a problem, since Julian intends to make majors and minors "go away". This is a very good thing, but it will require you use your first apprach. I don't think the change should be all that difficult. The main issue is how to convert one driver at a time. I think this can be done with common glue code on top to make them look like the old drivers for the near term. > On another note, how do people feel about more complex data structures > becoming standard parts of the kernel. I think there are a number of > places that using a more complex data structure would be a big win. > I have code for both Fibonacci Heaps and B-tree's that just need some > cleaning up to be generally useful. The code bloat would actually be > quite small. The Fib heap code is under 3k, and the B-tree code is > 4736 bytes, but this includes some debuging code (printing tree and > checking that the tree is in order). I would like to see the Fibonacci code in there... the B-tree code, I don't know; is there a plan to convert the routing code? 8-) 8-) 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712181929.MAA11029>