From owner-freebsd-hackers Fri Jan 23 03:55:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA23386 for hackers-outgoing; Fri, 23 Jan 1998 03:55:31 -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.8/8.8.8) with ESMTP id DAA23381 for ; Fri, 23 Jan 1998 03:55:27 -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 JAA15030; Fri, 23 Jan 1998 09:55:37 -0200 Received: by papagaio.voga.com.br(Lotus SMTP MTA v1.06 (346.7 3-18-1997)) id 03256595.00470040 ; Fri, 23 Jan 1998 09:55:31 -0300 X-Lotus-FromDomain: VOGA To: mike@smith.net.au cc: hackers@FreeBSD.ORG Message-ID: <83256595.0045CB26.00@papagaio.voga.com.br> Date: Fri, 23 Jan 1998 09:55:25 -0300 Subject: Re: uiomove() Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk > 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. Yep, I'm using separate read and write interfaces. > Can the card only handle one character at a time? How > slow is it handling a character/block? The card has single character and eight characters modes, but it is terribly slow in either mode. If I block everything until I finish the operation, I can gain about 20% in the 8 characters mode (which still must be feed one by one). As it is, both modes are taking almost the same time to process. The main problem is that I don't have a precise definition of how much time each operation takes. I only know some operations take up to a second to complete. The 512 bytes buffer I used to test the driver currently takes me 21 seconds to be processed, a reasonable amount of this time, it seems, taken by context switches. I plan to reduce it further using wakeup instead of 1 tick tsleeps (as I'm doing right now). > Do you (plan to) handle more than one writer at a time? Do > you synchronise writers and readers? The card is too stupid to handle multiple readers/writers (though I only realised that, and simplified the driver, after someone asked me how I saved context from stream to stream). I only accept one open() at a time. > Your calls won't be preempted unless another is called from an > interrupt context. What about SMP? > splsoftclock() is probably the one you want. Thanks. Still, I'd really appreciate knowing the difference between splsoftclock and splsofttty... > 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. A working queue was my first take on this, but since, as it is, it will gain me nothing, I decided on my current model. -- Daniel C. Sobral (8-DCS) Daniel_Sobral@voga.com.br Tagline: * FreeBSD. Earth.