Date: Fri, 23 Jan 1998 07:39:53 -0500 From: "Alfred Perlstein" <perlsta@sunyit.edu> To: <daniel_sobral@voga.com.br>, <mike@smith.net.au> Cc: <hackers@FreeBSD.ORG> Subject: Re: uiomove() Message-ID: <199801230845.IAA11935@fang.cs.sunyit.edu>
next in thread | raw e-mail | index | archive | help
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. > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801230845.IAA11935>