--G44BJl3Aq1QbV/QL
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 29, 2006 at 05:07:37PM -0400, der Mouse wrote:
> > I'm writing a device driver for a device that has i/o on both the ISA
> > bus and on a GPIO pin.  Obviously I need to map handles for both
> > busses so I can do I/O for the device, but I don't know how to write
> > the CONFIG file entry for the device.
>=20
> There may be some better way to represent it, but what I'd probably do
> is to make it two devices from the point of view of config.  Those two
> device's drivers would then have some private form of communication
> between themselves.  I'd probably make both drivers just thin glue
> layers in front of a single shared file that contained all the real
> guts for both (the latter being compiled based on a attribute attached
> to each of the other devices, and with care taken to make sure it does
> something sensible if only one of the devices is configured in), but
> there are doubtless other ways to do it.
>=20
> You might want to look at the way wscons is put together; that has
> cases where things that appear in disparate parts of the autoconfig
> tree - keyboards and displays - need to be stuck together.

See also the interactions between attimer(4) and pcppi(4).  For that I
used config_defer, which is enough because both devices are expected to
have a common parent.  Using config_defer works as long as you can
locate a common ancestor (not only know it, but get the associated
struct device).  Otherwise you can you config_interrupts, which will
enable the devices to talk to each other at a point where you're certain
both have attaches, even though the 'interrupts' part makes it a bit
hackish.

--=20
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"When I find the controls, I'll go where I like, I'll know where I want
to be, but maybe for now I'll stay right here on a silent sea."
KT Tunstall, Silent Sea, Eye to the Telescope, 2004.

--G44BJl3Aq1QbV/QL
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iQEVAwUBRKRY1NgoQloHrPnoAQKmXwf/S8Ru2q/KlsOkkzTr5mj0zSnxG9K4ZqHS
WamrJ8Z5qAlxo7o3Urb5bNXL6STtMDSL2ewzPpMtJfiSnjHBuudD6OZRyXM/1J4b
5wVdGPPakC0hghT7LU4GgXHAzyojCgSgMHsURI0H0GPeIYFgoRyeZEX0fXisVAcX
poeB3babAiXqhNH93WnhLhwKZOjlmyaS66Q41tdqUS4k7XI48ZS1imKcDCiqc+lW
TIKPfX3Xj4UA8lfkBnbZYmSsv/Ky+jdwDUJ02LN5UwyNp1ONljZU7q4++NLKVhFm
V1soHemIg1k5Wj9QJ63QPHmKaIYVqVZIRiVaBezMz0jdRSLuZrih2A==
=t2Yu
-----END PGP SIGNATURE-----

--G44BJl3Aq1QbV/QL--