Date: Fri, 23 Jan 1998 12:09:19 -0300 From: daniel_sobral@voga.com.br To: mike@smith.net.au Cc: mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: uiomove() Message-ID: <83256595.0050574F.00@papagaio.voga.com.br>
next in thread | raw e-mail | index | archive | help
> > Yep, I'm using separate read and write interfaces.
> Do you have to do this? Are all your consumers in
> the kernel?
No, none of my consumers are in the kernel at the present moment, in fact.
I decided that if they (the people who asked me to write the driver) wanted
to access it from the kernel, they would use the cdevsw interface, and
provide the process context needed. At the present, they don't need it
enough to either provide a process context nor require me to write it their
way... :-)
I'm using the read()/write() interface because it was there... :-) Anyway,
they could have separate processes to read and write, and it really doesn't
give me much trouble to let them do it.
> You could use an exponential backoff,
I thought of that. Just not pursued as yet. This would fall under the
"optimization" category, and, though the driver already works, I'm
currently trying to remove the bugs I know of, so I can say "it's ready".
> I would be inclined to try to gather some data on the average
> performance of the card in order to improve such a computation.
I did some of that for the encryption/decryption. I know already that
having DELAYs of 10ms for the 8 character mode, and 20ms for the 1
character mode, here and there helps. I'm not sure which are required,
which are optional, and I don't know which would require more than 50ms
(the highest delay I tried as yet). The other functions supported by the
driver/device are too many and, compared to the time taken by
encryption/decryption, not worth trouble.
> I think that was me. 8)
Yeah, I think so too. Just not sure... :-) Actually, I was not asked for
multiple stream support, but, since I decided to do it right anyway...
until I realised I couldn't. :-)
> Only accepting one open won't save you from multiple
> writers. (Think about fd inheritance from parent to
> child.)
I thought. That was one of the reasons I decided on a read()/write()
interface instead of a single crypt() one. The thing is... it's a character
device. So, one open, one stream. They may have multiple processes with fds
to it, but all from a single open. If they are dumb enough to treat it as
multiple streams, well, they deserve whatever they get. :-) I even thought
of calling something on at_fork, but decided on a KISS stance instead. If
it is in the man page, it's documented enough.
> If you only support one stream at a time, there is no requirement
> to synchronise your input or output at all. I would do something
> like this:
> s = splsoftclock();
> while (sc->nwaiting > 0) {
> tsleep(&sc->nwaiting, PCATCH, "cryptwrite", 0)
> }
> splx(s);
I have seen code like this elsewhere... tell me, won't crypt_timeout() be
blocked by splsoftclock() during the tsleep()? (The answer seems to be
"obviously, no", but I'd rather be sure than obvious. :)
Also, since you do splsoftclock(), wouldn't a PRISOFTCLOCK (if there is
such a beast) be reasonable as a parameter to tsleep()?
Also, isn't "cryptwrite" too big for tsleep()... :-) :-)
Anyway, that's about what I have, except that you use two buffers, I use
one, and you use fixed-sized chunks, where I use whatever the user
requests. I don't have a wakeup() right now, but that has been in my plans
for two days now... :-)
I may end up using your hmuch trick, though.
> Device drivers are currently exclusive. If you're really worried
> about SMP, ask the SMP people about how to obtain a lock and wait
> against one.
Well, done (sent a message to -smp). Let's see what they say.
> splsoftty() prevents soft tty interrupts (timeouts used for tty
processing).
> splsoftclock() prevents software clock (timer) interrupts.
So... timeout(9) is blocked by splsoftclock(), and splsofttty() may or may
not block timeout(9) (probably "may"), but do block other kinds of timeouts
I have not seen (because I have read much of tty code) which are used by
tty?
--
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?83256595.0050574F.00>