From owner-freebsd-hackers Fri Jan 23 05:51:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA01869 for hackers-outgoing; Fri, 23 Jan 1998 05:51:17 -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 FAA01863 for ; Fri, 23 Jan 1998 05:51:14 -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 JAA12460; Fri, 23 Jan 1998 09:51:17 GMT Message-Id: <199801230951.JAA12460@fang.cs.sunyit.edu> From: "Alfred Perlstein" To: "Mike Smith" Cc: , , Subject: Re: uiomove() Date: Fri, 23 Jan 1998 08:43:07 -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? > This doesn't necessarily help; if a process holding an open descriptor > on your device forks, there are now two processes holding open > descriptors but there has been no second open() call. This has been > discussed to death. ooops :) > > what's the point of an encryption card if you can't have multiple processes > > acesses it, at least "transparently" in parrallel? > I dunno, but the card in question performs stream, not block > encryption, and there is no mechanism (that Daniel seems to know of > anyway) to recover context from the card to allow switching streams. is this a "Fred's(tm) encryption card"? :) -Alfred