Date: Fri, 24 Oct 1997 15:49:41 +0930 From: Mike Smith <mike@smith.net.au> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: Mike Smith <mike@smith.net.au>, mobile@FreeBSD.ORG Subject: Re: Bus arch ramblings (was Re: Patches from -current for -stable ... Message-ID: <199710240619.PAA01789@word.smith.net.au> In-Reply-To: Your message of "Thu, 23 Oct 1997 23:01:47 MST." <19971023230147.53852@hydrogen.nike.efn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
(Should we be moving this off -mobile?) > > 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... Exactly. So why is it that a module can only know it's been loaded if it happens to be a device driver that matches some currently-present hardware? > > 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... So now every sysctl node has to contain an optional module reference. And every callout everywhere in the entire kernel likewise. And you have to traverse *all* of these in order to remove a module? Now how about a module that's allocated memory using the kernel malloc; you have to track that as well, and walk the entire malloc pool... Isn't it clear that it's easier to just have the module track its own resources, and back them out before leaving? > > 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... ... which is exactly what you're arguing against above. I'm confused now. > > - 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... There will *have* to be bus-specific code, but it should be limited to dealing with the bus hardware and translating between the bus' specific view of the world and either the abus or bbus models. > > > > 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 I meant "where is your whiteboard"? I have that one already 8) mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710240619.PAA01789>