From owner-freebsd-hackers Wed Jan 7 02:44:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA09964 for hackers-outgoing; Wed, 7 Jan 1998 02:44:03 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from db2server.voga.com.br (db2server.voga.com.br [200.239.39.7]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA09934 for ; Wed, 7 Jan 1998 02:43:55 -0800 (PST) (envelope-from daniel_sobral@voga.com.br) From: daniel_sobral@voga.com.br Received: from papagaio.voga.com.br (papagaio.voga.com.br [200.239.39.2]) by db2server.voga.com.br (8.8.3+2.6Wbeta9/8.8.7) with SMTP id IAA12022; Wed, 7 Jan 1998 08:44:27 -0200 Received: by papagaio.voga.com.br(Lotus SMTP MTA v1.06 (346.7 3-18-1997)) id 03256585.00407B4B ; Wed, 7 Jan 1998 08:44:18 -0300 X-Lotus-FromDomain: VOGA To: mike@smith.net.au cc: hackers@FreeBSD.ORG Message-ID: <83256585.003EA128.00@papagaio.voga.com.br> Date: Wed, 7 Jan 1998 08:44:09 -0300 Subject: Re: Device Driver Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk > "More input?" Ok, let me try for "more input"... > Will you be using it to perform end-to-end encryption on sockets? Yup. > How about encrypting the entire contents of ethernet datagrams? Nope. Only the contents of IP packets. Possibly the contents of UDP and TCP packets instead (as I said, that part I am not responsible for). > Is the output of the card complete in itself, or > does it encrypt streams of data? Apart from the various miscellaneous functions, which fit nicely into ioctl, the card does stream encryption, though access to it may be optimized by using it's 8-byte internal buffer. > Again, that depends on how you talk to it. Sometimes you will use the > standard device entries (if you plan to use those semantics from > elsewhere in the kernel), and sometimes you need other interfaces. The problem I see with using the standard device interface is the proc* parameter. The net functions calling the driver will be activated by interrupts. BTW, let me ask a question before I forget it again... :-) The driver itself has no interrupt handler. Now, I intend to use a queue to control the access to the card, and the queue manipulation section is critical. These routines _may_ be called from other interrupt handlers. So, should I spl them? At what level? -- Daniel C. Sobral (8-DCS) Daniel_Sobral@voga.com.br