From owner-freebsd-mobile Thu Oct 23 23:59:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA28237 for mobile-outgoing; Thu, 23 Oct 1997 23:59:25 -0700 (PDT) (envelope-from owner-freebsd-mobile) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA28231 for ; Thu, 23 Oct 1997 23:59:21 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id XAA20413; Thu, 23 Oct 1997 23:59:08 -0700 (PDT) Message-ID: <19971023235908.26084@hydrogen.nike.efn.org> Date: Thu, 23 Oct 1997 23:59:08 -0700 From: John-Mark Gurney To: Mike Smith Cc: mobile@FreeBSD.ORG Subject: Re: Bus arch ramblings (was Re: Patches from -current for -stable ... References: <19971023230147.53852@hydrogen.nike.efn.org> <199710240619.PAA01789@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199710240619.PAA01789@word.smith.net.au>; from Mike Smith on Fri, Oct 24, 1997 at 03:49:41PM +0930 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-mobile@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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