From owner-freebsd-hackers  Fri Jan 23 04:45:53 1998
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id EAA27581
          for hackers-outgoing; Fri, 23 Jan 1998 04:45:53 -0800 (PST)
          (envelope-from owner-freebsd-hackers@FreeBSD.ORG)
Received: from fang.cs.sunyit.edu (root@fang.cs.sunyit.edu [192.52.220.66])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA27575
          for <hackers@FreeBSD.ORG>; Fri, 23 Jan 1998 04:45:51 -0800 (PST)
          (envelope-from perlsta@sunyit.edu)
Received: from win95.local.sunyit.edu (A-T34.rh.sunyit.edu [150.156.210.241]) by fang.cs.sunyit.edu (8.8.5/8.7.3) with ESMTP id IAA11935; Fri, 23 Jan 1998 08:45:39 GMT
Message-Id: <199801230845.IAA11935@fang.cs.sunyit.edu>
From: "Alfred Perlstein" <perlsta@sunyit.edu>
To: <daniel_sobral@voga.com.br>, <mike@smith.net.au>
Cc: <hackers@FreeBSD.ORG>
Subject: Re: uiomove()
Date: Fri, 23 Jan 1998 07:39:53 -0500
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1161
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk

I'm hoping i don't get yelled at here, but why not queue all subsequent
open operations and block those processes operations on the device?
at least until a read is done?

what's the point of an encryption card if you can't have multiple processes
acesses it, at least "transparently" in parrallel?

-Alfred

> 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.
> 
>