Date: Thu, 18 Dec 1997 05:38:40 -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: <19971218053840.15389@hydrogen.nike.efn.org> In-Reply-To: <199712181323.FAA04229@resnet.uoregon.edu>; from Darren Reed on Fri, Dec 19, 1997 at 12:23:04AM %2B1100 References: <19971218044804.38303@hydrogen.nike.efn.org> <199712181323.FAA04229@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:
> >
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971218053840.15389>