dgatwood@gatwood.net writes:

On Tue, 20 Nov 2001, Sean Morrell wrote:

...

What forms of IPC can be used for communicating between a user

application

...

and a device driver?

Well, lots of stuff. That's kind of a broad question. You could use a

sysctl, RPC, an ioctl, good old raw Mach IPC (ick).... It really depends

on what you're trying to do. Are you writing a driver whose client is

primarily in user space, or are you writing a driver for which you simply

want to tune run-time parameters from user space?

If you are just trying to tune parameters, I'd think you'd probably be

best served by just adding a BSD sysctl or possibly an ioctl.

If, however, the primary client is in user space, you should look into the

way user clients/device interfaces are being done in other areas and

consider adopting that design.

Also, if your primary client is in user space, you should also consider

writing your driver entirely in user space, rather than putting it in the

kernel, then using sockets or posix shared memory or pipes to communicate

with the driver.

So again, what is it you're trying to do? :-)

Actually, the driver is for an audio device. And the user space application is nothing more than a system preference pane, needed only to configure the device. The audio device has some pecularities making it unconfigurable using the typical CoreAudio interface. I do have the option of using an Audio HAL Plug-In. But I just wanted to see if another IPC method might quicken the development. At this time, I simply need a one way notification to the driver. Eventually the driver will need to respond to the preference pane, returning small structures of data. In both cases, what IPC would you recommend? Thanks, Sean

Later,

David

---------------------------------------------------------------------

Check out my weekly web comic:

http://www.techmagazine.org