Date: Thu, 23 Oct 1997 22:08:57 -0700 From: John-Mark Gurney <gurney_j@efn.org> To: Mike Smith <mike@smith.net.au> Cc: Nate Williams <nate@mt.sri.com>, mobile@FreeBSD.ORG Subject: Re: Patches from -current for -stable I'd like to commit after testing Message-ID: <19971023220857.42676@hydrogen.nike.efn.org> In-Reply-To: <199710240426.NAA01201@word.smith.net.au>; from Mike Smith on Fri, Oct 24, 1997 at 01:56:48PM %2B0930 References: <19971023211408.08161@hydrogen.nike.efn.org> <199710240426.NAA01201@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith scribbled this message on Oct 24: > > > > and other possibles values are MOD_UNLOAD and MOD_SHUTDOWN... in the > > long run, I think it's much better to seperate the load proccess from > > the device driver... I guess we could make a seperate bus for these > > sorts of things.. but in my opinion it turns into an overkill... > > 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... > 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... > > basicly, as far as I can tell, there are two types of busses... abus > > is an address bus... each device is able to be addressed on this bus, > > and you are able to uniquely get a key that identifies this device.. > > this currently covers eisa, pci, pnp, mca, scsi, pccard, and more... > > then there is bbus, which is a bus bus.. everything listens to it and > > you have to magicly know what devices are listening.. :) currently only > > isa (and possibly vlb) are under this category... they will require > > a hard definition somewere for them to work... > > 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.. > This is very clean. There are a few nasty-ish warts; the data passed > to the attach routine will have to allow for opaque registration of > interrupt handlers etc. and likewise the structure provided to probe > routines will have to be *very* carefully generic, but still this would > be a huge improvement. oh.. don't worry, check out my spec... there are no resources that are global per say... you have to obtain access to the resources through the bus code... this will return the appropriate information that provides the access... > > I was thinking that we could make the table that is dynamicly loaded > > that contains the isa bus information.. then to probe some new devices, > > a table with that new entry is loaded, and then a bus rescan is started > > which will notice the new, unprobed device, and will probe it... > > 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... :) > 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.. :) also... as you probably see, I have most of the code->device, and device->bus interaction.. but I haven't got much of the code->bus interaction that provides the addresses... 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... could you attend classes and do my Physics work? :) -- 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?19971023220857.42676>