From owner-freebsd-hackers Fri Jan 9 05:39:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA20304 for hackers-outgoing; Fri, 9 Jan 1998 05:39:57 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from word.smith.net.au (ppp11.portal.net.au [202.12.71.111]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA20300 for ; Fri, 9 Jan 1998 05:39:48 -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 AAA00656; Sat, 10 Jan 1998 00:02:49 +1030 (CST) Message-Id: <199801091332.AAA00656@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 "Fri, 09 Jan 1998 11:35:33 -0300." <83256587.004F044C.00@papagaio.voga.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 10 Jan 1998 00:02:49 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk > > > 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. > > [snip] > > > I have to be honest; it really sounds like you have embarked on a > > product without actually *designing* the damn thing first. > > Then it doesn't sound right... :-) The product exists, and it's not mine. > I'm just writing a driver for an encryption card that will be used by the > product. Anyway, thanks for all the help. It seems all my problems haven > been solved. Ok. I think I haven't understood what you're attempting to achieve. Anyway. > In the end, I decided using tsleep, and they'll be creating a kernel > process and accessing the device through it's normal interface. > > BTW, if I read the source code right, one "unit" of tsleep normally > corresponds to 1/128 seconds, and 1/1024 while profiling, is that right? Each tsleep() count corresponds to 1/hz seconds, where hz should be considered opaque. -- \\ 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. \\