From owner-freebsd-hackers Fri Jan 9 04:47:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA15863 for hackers-outgoing; Fri, 9 Jan 1998 04:47:13 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from word.smith.net.au (ppp3.portal.net.au [202.12.71.103]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA15849 for ; Fri, 9 Jan 1998 04:47:01 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id XAA00419; Fri, 9 Jan 1998 23:09:17 +1030 (CST) Message-Id: <199801091239.XAA00419@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: daniel_sobral@voga.com.br cc: mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: Device Driver In-reply-to: Your message of "Thu, 08 Jan 1998 08:33:32 -0300." <83256586.003E86D0.00@papagaio.voga.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 09 Jan 1998 23:09:17 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk > > > 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. \\