Date: Thu, 23 Oct 1997 23:01:47 -0700 From: John-Mark Gurney <gurney_j@efn.org> To: Mike Smith <mike@smith.net.au> Cc: mobile@FreeBSD.ORG Subject: Re: Bus arch ramblings (was Re: Patches from -current for -stable ... Message-ID: <19971023230147.53852@hydrogen.nike.efn.org> In-Reply-To: <199710240539.PAA01521@word.smith.net.au>; from Mike Smith on Fri, Oct 24, 1997 at 03:08:59PM %2B0930 References: <19971023220857.42676@hydrogen.nike.efn.org> <199710240539.PAA01521@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith scribbled this message on Oct 24: > > > I don't think that it'll ever be possible to avoid having load/unload > > > actions in a device driver module; drivers may want to allocate local > > > storage, and they're the last arbiter as to whether they are ready to > > > be unloaded, so whether you overload "LOAD" as "first probe" and > > > "UNLOAD" as "last close", or make them explicit, the same actions are > > > relevant. > > > > ok... well.. I think that should be covered by the attach/detach > > events... > > You're missing the point here; attach/detach is tied to a device > instance, not a module instance. We're not just talking device driver > modules here, and even they may have per-module rather than per-device > setup/teardown. hmm... what is a device driver module?? a module is just set of a name, a handler routine, and an arg... nothing more... > > > If the "kernel registry" stuff ever happens, or any other form of > > > parametric access, there is scope for references into the driver > > > outside the domain of open/close, and you still need a way of cleaning > > > this up. Load/unload hooks are the only way to go. > > > > hmmm... if it's part of a module that you load, you could just unload > > it.. and this is what I'm thinking about... > > Ok, so as a part of my module startup, I create a new sysctl node, > which references a parameter in my address space. When I'm unloaded, > that reference becomes invalid (and lethal). Short of attaching ok... so you add a reference to your module.. and when the unload event comes you either a) remove it, or b) revoke the removal... > ownership attributes to everything like this (and there are lots of > things that fall into this categorty), the *only* way to handle the > departure of a module is to have the module itself clean up before it > allows you to remove it. yep.. that's what the handler allows... my dummy module (the first that I used to test the new code) scheduled a timeout.. then upon unloading I used untimeout to remove it... > > > Hmm, so you are proposing to avoid anything bus-specific in your driver > > > model? ie. the driver provides a 'probe' function if it supports bbus > > > operation, and alwyas provides an 'attach' which is called directly by > > > abus stuff and indirectly as a result of a successful bbus probe? > > > > pretty much yes... I was still thinking about calling probe from abus > > code too... but this can be eliminated if we provide for a way to tell > > how long each key is... and probably should be the way it's done.. > > The driver should never see the key: > > - bus-specific code accesses peripheral according to bus standard, > extracts identification tokens and resource information agreed... > - bus-specific code looks up identification tokens in bus-specific data > structure, and determines abus-specific driver identification. > - bus-specific code passes abus-specific driver identification and > resource information in abus format to abus code > - abus code locates driver using identification supplied, calls driver > attach function with resource data before I started working on the project, I used to agree with that statement... it will still be possible to overload the two bus types that I provide (abus and bbus), and expand it.. but the reason I want to write the abus and bbus is to remove duplicate code that each of the bus-specific code would normally have to write... > > > So, big question: What can we do to help you with this? > > > > well.. you could take a look at my spec, and provide input.. remeber > > though.. it's still under work, and that my real work is on my white > > board in my room.. :) > > Which is at what URL? http://resnet.uoregon.edu:6971/~jmg/FreeBSD/busdevice.html sorry for the long url, but that's my home machine.. :) > > right now I'm thinking of providing the bus a way to notify my code > > that an address/device has arrived... then each address on the bus > > will have a message delievered to my code that it exists (this fits > > in nicely with interrupt driven scsi probing :) ), and then the code > > will probe/attach the device if there is a driver available... > > Isn't this the whole idea? In the case of static busses like PCI, > startup is a flurry of arrival events, while with things like PCCARDs > and USB it's much more dynamic. yep... I just haven't writen that part of the spec... just making sure you knew what I was intending.. -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking 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?19971023230147.53852>