From owner-freebsd-hackers Fri Jan 23 03:36:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA22371 for hackers-outgoing; Fri, 23 Jan 1998 03:36:04 -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.8/8.8.8) with ESMTP id DAA22341 for ; Fri, 23 Jan 1998 03:35:57 -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 VAA00262; Fri, 23 Jan 1998 21:58:20 +1030 (CST) Message-Id: <199801231128.VAA00262@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: daniel_sobral@voga.com.br cc: hackers@FreeBSD.ORG Subject: Re: uiomove() In-reply-to: Your message of "Fri, 23 Jan 1998 09:19:04 -0300." <83256595.0043094E.00@papagaio.voga.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Jan 1998 21:58:18 +1030 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk > > Ok, so here is the deal. Since this is an encryption card, what I do is > write each character to the card and then read the encrypted character > back. So, write() writes the data to a circular buffer, and read() reads > from a circular buffer. Er. Why do it that way? I presume that you are passed a pointer to a linear region containing "plaintext", and your task is to convert it into "ciphertext". Am I close? If not, then I assume that you have separate write and read interfaces. Can the card only handle one character at a time? How slow is it handling a character/block? > I'm using a single circular buffer, with three pointers: last character > written (+1), first character to be read, and next character to be > encrypted/decrypted. Write() is very simple, indeed. After writing data to > the buffer, it timeout()s a function which will be doing the conversion. Do you (plan to) handle more than one writer at a time? Do you synchronise writers and readers? > So, read() is tsleeping on PZERO priority, so crypt() can be called. Now, > there is a few race windows. First, if read() and write() are called > simultaneously and one of them preempts the other, there might be a race > window. I don't know if one of them can preempt another or not. Your calls won't be preempted unless another is called from an interrupt context. > Another > race window happens between read() and crypt(). That one seems easier to > get rid of, but spl0() is not what I want, since I cannot splx() after > that. It seems splsoft*() is what I want, but I don't know which. splsoftclock() is probably the one you want. > Splitting read and write buffers would eliminate the race between read() > and write(), and introduce a race between write() and crypt(), which may be > helpful. > > Anyone wants to enlight me? TBH, I would suggest that a "work queue" approach would be a more efficient way to go, but this presumes on a single crypt() call rather than seperate read/write calls. With split calls, it becomes difficult to guarantee synchronisation between multiple callers. -- \\ 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. \\