Date: Thu, 23 Oct 1997 23:59:08 -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: <19971023235908.26084@hydrogen.nike.efn.org> In-Reply-To: <199710240619.PAA01789@word.smith.net.au>; from Mike Smith on Fri, Oct 24, 1997 at 03:49:41PM %2B0930 References: <19971023230147.53852@hydrogen.nike.efn.org> <199710240619.PAA01789@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith scribbled this message on Oct 24: > (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. wierd... I thought I was arguing for the module tracking it's own resources... and refusing to unload when it gets the unload event.. :) > > > - 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. agreed... > > > > > 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) ahh.. ok.. if someone could mail me an electronic whiteboard.. I'd gladly use that instead... :) I'll see what I can do about updating the page in the next few hours.. I have some other work to do... thanks for the input... -- 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?19971023235908.26084>