Date: Fri, 09 Jan 1998 23:09:17 +1030 From: Mike Smith <mike@smith.net.au> To: daniel_sobral@voga.com.br Cc: mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: Device Driver Message-ID: <199801091239.XAA00419@word.smith.net.au> In-Reply-To: Your message of "Thu, 08 Jan 1998 08:33:32 -0300." <83256586.003E86D0.00@papagaio.voga.com.br>
next in thread | previous 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. Ah! You are building an encrypting *router*. Everything becomes much much much more complicated. You have to maintain state for *all* of the connections whose datagrams you are routing. This is respectably nontrivial. For a framework that you might want to look at wrt. getting datagrams to a point where you can process them look at the 'natd' port's mode of operation. With this, you can just us a fairly normal character device driver interface for your encrypting card, but you will have to live with four kernel boundary crossings for routed packets. > > 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... Don't; splnet the code that *calls* it. I have to be honest; it really sounds like you have embarked on a product without actually *designing* the damn thing first. I normally charge lots of money to be part of this sort of process. 8) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801091239.XAA00419>