Date: Thu, 8 Jan 1998 08:33:32 -0300 From: daniel_sobral@voga.com.br To: mike@smith.net.au Cc: mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: Device Driver Message-ID: <83256586.003E86D0.00@papagaio.voga.com.br>
next in thread | raw e-mail | index | archive | help
> This is not necessarily the case. For outbound data, > the call to enqueue the data (at least) will be made > by the sending process. It would not be unreasonable > for the send to block the process until encryption is > completed. > For incoming data, the decryption could be postponed > until the consumer actually reads from the socket, > although as soon as you have a socket in mind you have > access to the proc structure belonging to the socket's > owner. I'm not sure. Most packets will be just routed. > Another alternative would be to create a kernel process > (like the update daemon) which serviced the > encryption/decryption queues. This would give you a > process context on which you could sleep. I'll look into that. > What level are you going to call them from? Network interruptions. It's just that it feels kind of weird splnetting the code even though it's not necessarily network related... > Are you capable of writing queue manipulation code that > can survive interleaved head and tail operations? I intended to use the queue macros, like style(9) advised to. And, yes, I can write that code, but that's still not exactly reentrant, is it? :-) -- Daniel C. Sobral (8-DCS) Daniel_Sobral@voga.com.br
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?83256586.003E86D0.00>