From owner-freebsd-mobile Thu Oct 23 23:02:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA25794 for mobile-outgoing; Thu, 23 Oct 1997 23:02:07 -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 XAA25780 for ; Thu, 23 Oct 1997 23:02:01 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id XAA20206; Thu, 23 Oct 1997 23:01:47 -0700 (PDT) Message-ID: <19971023230147.53852@hydrogen.nike.efn.org> Date: Thu, 23 Oct 1997 23:01:47 -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: <19971023220857.42676@hydrogen.nike.efn.org> <199710240539.PAA01521@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199710240539.PAA01521@word.smith.net.au>; from Mike Smith on Fri, Oct 24, 1997 at 03:08:59PM +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: > > > 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