Date: Fri, 24 Oct 1997 13:56:48 +0930 From: Mike Smith <mike@smith.net.au> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: Mike Smith <mike@smith.net.au>, 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: <199710240426.NAA01201@word.smith.net.au> In-Reply-To: Your message of "Thu, 23 Oct 1997 21:14:08 MST." <19971023211408.08161@hydrogen.nike.efn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. 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. > 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? 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. > 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 So, big question: What can we do to help you with this? mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710240426.NAA01201>