Date: Fri, 24 Oct 1997 15:08:59 +0930 From: Mike Smith <mike@smith.net.au> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: mobile@FreeBSD.ORG Subject: Bus arch ramblings (was Re: Patches from -current for -stable ... Message-ID: <199710240539.PAA01521@word.smith.net.au> In-Reply-To: Your message of "Thu, 23 Oct 1997 22:08:57 MST." <19971023220857.42676@hydrogen.nike.efn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > 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. > > 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 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. > > 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 - 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 > > If you go back through your archive to the discussions that Stefan, > > Luigi(?) and I were having on this a few months back, I think > > yeh... I remeber that discussion.. I thought I was in it a bit... :) You and a dozen or so others. 8) > > 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? > 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. > could you attend classes and do my Physics work? :) Hmm. No, but there's gotta be at least one physicist on the list. 8) mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710240539.PAA01521>