Re: ipf_inject_input returns ENOTSUP
Re: ipf_inject_input returns ENOTSUP
- Subject: Re: ipf_inject_input returns ENOTSUP
- From: Josh Graessley <email@hidden>
- Date: Wed, 21 Sep 2005 13:21:54 -0700
On Sep 21, 2005, at 11:53 AM, Allan Hoeltje wrote:
Sorry, I want to be absolutely clear on this.
1) My kext should send IP packets to my user app with ctl_enqueuembuf.
Therefore, my user app should read the packets with "recv" or
"recvmsg"?
That's correct.
2) My kext should receive IP packets from my user app with
ctl_send_func.
Therefore, my user app should send the packets with "send" or
"sendmsg"?
That's correct.
Send/recv are much easier to use and understand than sendmsg/
recvmsg but
will they work with ctl_send_func/ctl_enqueuembuf?
When a kext calls ctl_enqueuembuf or ctl_enqueuedata, that places
data in the receive queue of the kernel control socket. This in turn
may wake up any process waiting for data on that socket. An
application can read from a socket's receive queue using recv,
recvfrom, and recvmsg and a few others.
When an application calls a kernel control socket's send/sendto/
sendmsg, that triggers a call to the corresponding kext's ctl_send_func.
recvfrom and sendto probably wouldn't work because the kernel control
socket must be connected to a kernel extension first. Once connected,
there's no point in specifying the to/from.
These two mechanism allow bidirectional communication between a
process in user space and a kernel extension. The socket option
handling is good for modifying settings but suboptimal for carrying
vast quantities of data.
-josh
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden