On Mon, Nov 08, 2004 at 11:42:01AM -0800, Jeff Rizzo wrote:
> David Young wrote:
> 
> >
> >I would ask of the original poster, does the Asterisk architecture
> >observe this policy/mechanism, userland/kernel split?
> >
> >(I am dimly aware that STREAMS has something to do with all of this.)
> >
> > 
> >
> 
> Well, I find myself in the somewhat uncomfortable position of learning 
> about this as I'm doing it.  :)  From what I can see, it does indeed 
> keep out of the original audio stream as much as possible.
> 
> One of the things that's clear to me is that the current architecture of 
> the driver, however well it works under Linux, is probably not ideal for 
> NetBSD.

Yes, but that's really a matter of its divergence from our model for
device configuration and attachment, not of its divergence from some
hypothetical ideal model API for computer telephony.

You should be able to fix the internal details of how the driver is
organized so that it fits into our configuration framework without nearly
so much pain as would be involved in rototilling its API to the end user,
and rototilling Asterisk to use said freshly-rototilled API.  You have
all the bits that talk to the hardware; you just need to reorganize
them in a slightly different way.

> One thing I have learned since I made the original post:  apparently, 
> Linux open() calls have per-descriptor private data for the device;  the 
> FreeBSD port goes to some pains to emulate this by redefining file 
> operations for a new descriptor and setting the f_data field of 'struct 
> file' to point to this device-private data... I'm understanding a little 
> better what that's about, and am noodling over how to make that work in 
> NetBSD.

If the user/kernel interface for this device under Linux has semantics
that require per-descriptor private data, you can manage it under NetBSD,
though it's not tremendously pretty.  Have a look at the various
device implementations in the kernel modules that implement VMware
compatibility; they need to do that.  You might also want to have a look
at the "devvp" branch (or did we finally merge that?) which was intended
to make this sort of thing easier.

Thor