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

On Sun, Nov 07, 2004 at 10:24:29AM -0800, Jeff Rizzo wrote:
>=20
> Hi-
>=20
> For the last couple weeks, I've thrown myself into finally doing some=20
> driver work in the kernel, because I'd like to be able to run Asterisk=20
> (http://www.asteriskpbx.org/) with PSTN interfacing support under=20
> NetBSD.  The "zaptel" drivers have been ported (at least in part) to=20
> FreeBSD from Linux, and I've been working on getting the framework and=20
> one of the hardware drivers working under NetBSD.   I've learned quite a=
=20
> bit, to the point where I think I can finally ask the right questions. =
=20
> :-)=20
>=20
> First, I should probably explain the setup of the drivers themselves,=20
> since a big question I have is regarding how I should handle this=20
> particular kind of setup under NetBSD.  There is a main "zaptel" driver=
=20
> which does not attach to any hardware, but appears to provide a=20
> framework under which hardware drivers for various boards (FXS, FXO,=20
> T1/E1, etc) register themselves.  Under FreeBSD (and I assume Linux,=20
> though I haven't worked directly with the Linux drivers), the drivers=20
> are in kernel modules which get loaded;  the zaptel module first, then=20
> the hardware drivers (like the "wcfxs," which is the one I'm working=20
> with now).=20
>=20
> If I'm understanding the setup correctly, the hardware drivers (wcfxs,=20
> etc) don't actually have their own cdevsw structures, since they=20
> register with zaptel, and zaptel dispatches the various calls (open,=20
> close, ioctl, etc), to the appropriate hardware.   I've initially tried=
=20
> to set "zaptel" up as a pseudo-device, but now I'm running into trouble=
=20
> because pseudo-devices attach _after_ all the hardware has probed, so my=
=20
> hardware isn't being attached.

Note: you've run into a confusion I ran into with a coworker recently.=20
Having a driver show up as a character device is indepenant of it actually=
=20
driving hardware. It sounds like you want to:

1) Add a "zaptel" driver and compile it into the kernel. Add an entry to=20
the major number list. Model it after the audio layer.

2) Have the real drivers like "wcfxs" attach to the physical busses. Then=
=20
have them attach an instance for the zaptel layer.

I realize that I've not read the rest of the thread and this may have=20
already been covered. :-)

Take care,

Bill

--liOOAslEiF7prFVr
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFBkTZ4Wz+3JHUci9cRAvk7AJ95SUDUZDGtOKAWAxgJf6U8fGf+cACaA1TT
QvxJsmIsYwC56bexYQV456w=
=Msan
-----END PGP SIGNATURE-----

--liOOAslEiF7prFVr--