From owner-freebsd-hackers Thu Dec 18 05:39:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA18569 for hackers-outgoing; Thu, 18 Dec 1997 05:39:13 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA18559 for ; Thu, 18 Dec 1997 05:39:05 -0800 (PST) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id FAA09421; Thu, 18 Dec 1997 05:38:40 -0800 (PST) Message-ID: <19971218053840.15389@hydrogen.nike.efn.org> Date: Thu, 18 Dec 1997 05:38:40 -0800 From: John-Mark Gurney To: Darren Reed Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: converting drivers to dynamic memory... References: <19971218044804.38303@hydrogen.nike.efn.org> <199712181323.FAA04229@resnet.uoregon.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199712181323.FAA04229@resnet.uoregon.edu>; from Darren Reed on Fri, Dec 19, 1997 at 12:23:04AM +1100 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Darren Reed scribbled this message on Dec 19: > 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) ? 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.. :) ).. > Why isn't it ok to just free/allocate and the memory when it is (un)loaded ? well, the problem is mapping the major/minor number that the kernel gives you to the proper private data structs... > 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 ? nothing else cares about those buffers, but the problem is: static struct bpf_d bpf_dtab[NBPFILTER]; and d = &bpf_dtab[minor(dev)]; how do you dynamicly add another bpf device if you have static data that is required? (say you only compiled four, but need just one more).. -- 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