Re: Limitations Within a Driver
Re: Limitations Within a Driver
- Subject: Re: Limitations Within a Driver
- From: Louis Gerbarg <email@hidden>
- Date: Mon, 26 Nov 2001 14:11:52 -0800
I would only recommend using sysctl if your code lives inside the bsd
section of the kernel proper. I would tend to suggest you use get and
setProperties (and IORegistryEntryCreateCFProperty and friends in
userland) if you need a low bandwidth channel, or an IOUserClient if you
need a highbandwidth/low latency communication system.
Louis
On Monday, November 26, 2001, at 01:09 PM, Sean Morrell wrote:
email@hidden writes:
File I/O (meaning anything that goes through a file descripter,
including sockets and pipes) is just not a good thing from inside a
driver. From a strictly technical point you can do it, but it is
tricky,
expensive, and fragile. In short it is a bad idea. If you are asking
about BSD style signals, they are a process based concept, thread
delivery is difficult in userland when you are multithreaded. In the
kernel they just don't work like that.
So what must I use to communicate between my user land configuration app
and the driver? I have been told to use sysctl. Is this my only
option?
Can Mach IPC be used from user space? Is it recommended? Any other
options?
Louis
On Sunday, November 25, 2001, at 10:22 PM, Sean Morrell wrote:
Can named pipes, sockets and signals be used from within a driver,
specifically an I/O Kit kernel audio driver? I have been told that
disk
I/O cannot be performed from within a driver? Is this true? If so,
does
this exclude the use of a disk based IPC such as a named pipe?
Thanks,
Sean
_______________________________________________
darwin-kernel mailing list
email@hidden
http://www.lists.apple.com/mailman/listinfo/darwin-kernel