-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>
> Why didn't you just send to the list?! There might be someone else on
> the list who would jump in with the answers and the archives are useful
> for people who may have similar problem later.
>
>
Whoops.. My mistake. Looks like I forgot to adjust the recipient for
the last one =)
> I think you should have several logical buffers, just large enough to
> fill in one packet. It should be easiest to have different file
> descriptor for each of them, unless you need really many of them.
>
> Now each of these buffers can be in one of three states: processed by
> userland, processed by kernel or unused.
>
> When kernel would have received a packet it would put it in one of the
> unused buffers and wake up the daemon by returning POLL_IN from poll on
> respective descriptor. The daemon could then safely process the buffer,
> as the kernel is done with it.
>
> When the userland would have a packet to send, it would take one of it's
> buffers, fill the packet in and tell kernel to send it via ioctl.
>
> Now only one side could manage the free buffers. I think it should be
> the kernel. When the daemon would need a buffer, it would call an ioctl
> (on any buffer descriptor). The kernel would pick some (not necessarily
> the same) unused buffer and return POLL_OUT for it from poll. The daemon
> could of course request out a buffer or two in advance.
>
> This way each side would know which buffers it should work with and
> which are being processed by the other side. Only locking would be the
> lists of buffers inside kernel and for that spinlocks are the right
> tool.
>
That's a great idea..
I'm probably going to have to use a large number of buffers, so they
wouldn't be able to have their own file file descriptors.. However, I
could use a shared identifier for each, and use ioctls instead.
So...
* Have many different logical buffers, each one to hold a single
packet.
* Use an ioctl-based locking mechanism for each, managed by kernel
(probably)
* 3 states for each buffer: held by daemon (DAEMON), held by kernel
(KERNEL), unused (UNUSED).
1. Kernel, when receiving a packet, takes an unused buffer, and holds
it while it fills it up: Sets state to KERNEL.
2. Kernel releases buffer, and locks it for daemon: Sets state to
DAEMON.
3. Kernel notifies daemon of packet arrival with either a custom
signal, or by waking up from a block from an ioctl, which would
be nicer..
4. Daemon processes packet, which will probably include claiming of a
new buffer to put unencrypted packet into (during which the
daemon calls a ALLOCBUFFER ioctl to make kernel lock buffer
for daemon, setting state to DAEMON for that UNUSED buffer)
5. Once daemon is finished with old packet data, it releases, with a
FREEBUFFER ioctl, and kernel sets buffer to UNUSED.
6. Daemon passes new buffer to kernel, with a
INCOMING/OUTGOING ioctl.
7. Kernel claims buffer, setting state to KERNEL, and processes on
next process cycle.
So, sounds like it'll work - Thanks for the suggestion =)
Cheers =)
Mike
- --
Mike Tyson <mike@xxxxxxxxxxxxx>
M: (+61) 0407 754 124
W: http://tzidesign.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCsjmj/eih+gEb7pQRAv5rAKCQ88y7aajI6Jc2caFFmFcSTmtpfwCfTlEc
9KIFoKXa4KIjkuTcRHyC7fs=
=IPoU
-----END PGP SIGNATURE-----
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
