Date: Thu, 18 Dec 1997 06:36:06 -0800 From: John-Mark Gurney <gurney_j@efn.org> To: Mike Smith <mike@smith.net.au> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: converting drivers to dynamic memory... Message-ID: <19971218063606.31535@hydrogen.nike.efn.org> In-Reply-To: <199712181335.AAA00353@word.smith.net.au>; from Mike Smith on Fri, Dec 19, 1997 at 12:05:18AM %2B1030 References: <19971218035032.46460@hydrogen.nike.efn.org> <199712181335.AAA00353@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith scribbled this message on Dec 19: > > 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. > > This is traditionally the softc array (or pointer array), and not much > else. yes, but a few has multiple arrays (sio has two)... > > 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 > > I do not. And you have missed the most obvious (and most widely > discussed) solution, which various people are already working on. so, your saying that the rest of the frame would already exists, it just needs to be fixed? > Understand that when DEVFS hits us properly (and all that's holding it > up now are buggy consumers), dev_t will cease to be what it currently > is. The dev_t argument is present everywhere that you want to > reference your device softc. ok, if this is the case, can you tell me where this is currently?? I just looked at sio's devfs_add_devswf... the closest thing was the passing of it's unit number in, but then it gets or'd with the flag of what that entry does... PLUS, that "minor" number gets merged with the major number, so you won't be able to store a void * in there... so, two questions, where does devfs does this magic pointer? and how will it co-exist with passing back the type of device that was opened? > So, when you create your DEVFS node, one of the objects you pass in > will be stored in the device token that's passed back on all your > devices references. In the normal case, this will be a pointer to your > softc, which you can retrieve in the normal fashion. > > There will be no major/minor numbers soon. so, how long till this happens?? is this going to be completed in the next few months? the reason I ask is that once the bus/device code is writen, I'm going to have to pretty much rewrite ALL of the device drivers for the new scheme, and I don't want to do more than I have to... changing how a function is called is a LOT more work than just changing the internals of a function... -- 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?19971218063606.31535>