Date: Sun, 21 Dec 1997 13:10:12 +1030 From: Mike Smith <mike@smith.net.au> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: Mike Smith <mike@smith.net.au>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: converting drivers to dynamic memory... Message-ID: <199712210240.NAA01912@word.smith.net.au> In-Reply-To: Your message of "Thu, 18 Dec 1997 06:36:06 -0800." <19971218063606.31535@hydrogen.nike.efn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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? Framework? Yes, it's almost all there already. When your device is currently operated on, the dev_t value is constructed and passed in to the driver using the values from the device node. That construction will be replaced with the passing in of the devfs token for the node. > > 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'm not sure what you mean by "where this is". Do you mean "where are the code samples"? There are none yet; they wouldn't fit the current model. > 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? The pointer will be stored in the devfs node. I'm not sure I understand what you mean by "the type of device" though. When you create a devfs node, there is an association between the node and the device switch. The functions in the device switch will be passed the devfs token when the node is operated on. > > 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? This is entirely contingent on the acceptance of devfs as "the way to go", and the encompassing of the various prerequisite tasks (such as persistence and fixing buggy devfs support in drivers). > 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... I think that devfs will be a goer for 3.0. I don't know what sort of timetable you're on for your bus restructuring, but I suspect you may be looking at 3.1 for that. mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712210240.NAA01912>