Date: Thu, 23 Oct 1997 21:14:08 -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: <19971023211408.08161@hydrogen.nike.efn.org> In-Reply-To: <199710240332.NAA00908@word.smith.net.au>; from Mike Smith on Fri, Oct 24, 1997 at 01:02:43PM %2B0930 References: <19971023180601.65534@hydrogen.nike.efn.org> <199710240332.NAA00908@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith scribbled this message on Oct 24:
> >
> > ahh.. thanks for telling me this.. right now I'm looking at designing
> > a new bus/device interaction spec... and stuff like this is what I want
> > to know about.. :) with your addition I realized that having "fixed"
> > entries for probe/attach'ing is really stupid.. and that we should
> > actually go on an event based system where an even is delievered to the
> > device driver...
>
> This is pretty hot.
>
> > right now it's something like:
> > enum { DV_PROBE,
> > DV_ATTACH,
> > DV_DETACH,
> > DV_SUSPEND,
> > DV_RESUME
> > };
>
> DV_LOAD, DV_UNLOAD at least as well. (LOAD would be the first call
> made after the driver was linked in, UNLOAD would have to agree to
> being unloaded and invalidate all references to the driver.)
well.. this wouldn't work to well with the module code that Rabson
came up with... if you want to do that, you do something like:
static moduledata_t mytst = { "mytst", mytst_handler, (void *)100};
DECLARE_MODULE(mytst,mytst,SI_SUB_PSEUDO,SI_ORDER_ANY);
then mytst_handler is called like:
int mytst_handler(MOD_LOAD, (void *)100);
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...
> > int (*handler)(strcut device *dev, int event);
>
> There's no support there for passing in more event information; the
> probe would want to take a number of parameters varying on the bus
> support making the probe. eg. the PCI code would want to pass in PCI
> ID numbers and preset resource information. Likewise the PnP code
> would have information derived from the PnP data, and a vanilla ISA
> probe would have data derived from a static configuration.
well... I do provide for a key on an address bus (darn, my spec doesn't
have the defintion, see next paragraph), which would cover this... there
is resource information that is stored in this structure that provides
the resource info... I hadn't figured out how this was going to happen,
but it will...
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...
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...
--
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?19971023211408.08161>