Date: Fri, 19 Dec 1997 00:23:04 +1100 (EDT) From: Darren Reed <avalon@coombs.anu.edu.au> To: gurney_j@resnet.uoregon.edu Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: converting drivers to dynamic memory... Message-ID: <199712181327.FAA17836@hub.freebsd.org> In-Reply-To: <19971218044804.38303@hydrogen.nike.efn.org> from "John-Mark Gurney" at Dec 18, 97 04:48:04 am
next in thread | previous in thread | raw e-mail | index | archive | help
In some mail from John-Mark Gurney, sie said: > > Darren Reed scribbled this message on Dec 18: > > In some mail from John-Mark Gurney, sie said: > > > well... one of the things that will need to be done in preperation > > > for moving to a dynamic system which will be required by the bus/device > > > code, we will need to eliminate ALL static datat that depends upon > > > Ndevice to size itself. > > > > > > 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 guess the question is, do you want a `quick hack' or a real solution to > > fix and addres the problem ? > > > > How many hours did you spend on the B-Tree stuff and how many do you > > expect it would take to do it the other way ? > > the B-tree code is generic, I wasn't writing it to solve the above > problem, just so that I would have the code in my archives for use > when I need it.. :) so, time taken to write the B-Tree code shouldn't > be counted in the equation... > > the reason I say the second solution is that it MIGHT take a person > two hours for the largest device to convert from the current table of > static data to dynamic... [....] > if you do the second method, 90% of the work you do in that step will > be able to be reused for when you finally make the step to the first > method... so, it's more along the lines of, lets get the system into > a state that I can continue to do my work, and then when I or someone > else has time, finish the job. In the short term, getting the bus/device > code is a greater benifit then the minor loss of this "hack" to get it > working. 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) ? Why isn't it ok to just free/allocate and the memory when it is (un)loaded ? If, I load a device like BPF and tell it I want "NBPF" to be 4, then what else besides the BPF driver needs to know that NBPF is 4 ? (I hope I've picked a very simple case :). What else cares about those buffers ? > Reminds me of my social science teacher in high school. She said, > most people think that the cost of college is just that of the tuition > you pay, but you have to also figure in the loss of not being able to > use your time to work. *groan* no kidding. Going to conferences, as a contractor is *very* expensive. > > "Do it once and do it right." > > "If you have time to do it right, do it right, else get it working." :) Touche!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712181327.FAA17836>