Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 (MU) 9/23/84; site neology.OZ
Path: utzoo!watmath!clyde!cbosgd!ihnp4!mhuxn!mhuxr!ulysses!allegra!mit-eddie!think!harvard!seismo!munnari!basser!neology!chris
From: chris@neology.OZ (Chris Maltby)
Newsgroups: net.bugs.usg
Subject: Horrible ugliness in V.2 readi/writei.
Message-ID: <150@neology.OZ>
Date: Wed, 24-Jul-85 19:58:08 EDT
Article-I.D.: neology.150
Posted: Wed Jul 24 19:58:08 1985
Date-Received: Wed, 31-Jul-85 02:49:06 EDT
Organization: Neology Limited, Australia
Lines: 32

I just had enormous problems with writing the line printer part
of a dmf32 driver. I couldn't work out why it never did anything,
and behaved badly in general.  The problem turned out to be this
revolting code in the 5.2 readi/writei code:

	if (cdevsw[major(dev)].d_tty != NULL)
	{
		tp = &cdevsw[major(dev)].d_tty[minor(dev)];
		(*linesw[tp->t_ldisc].l_write)(tp);
	}
	else
		(*cdevsw[major(dev)].d_write)(minor(dev));

This part of the system has no right to assume what the code in a
driver's read/write routine does, even if it seems to be a tty driver.
It saves exactly one function call per tty write (when it's correct),
which is b*gger-all.  There is a much bigger scope for optimising
performance by trying harder to eliminate single char (or small) writes
in programs. You could gain as much by removing the common code of rdwr
and puuting it into both read and write, but they didn't think of
this.

Of course, I was using the top bit of minor(dev) to mean something
special.  You can understand the horrible bug it caused.  I don't know
where I would have been without the source.

P.S. I wasn't helped by DEC's DMF32 manual which states that the lp DMA
byte count register contains "a byte count". It REALLY means "a two's
complement byte count". This is different from the async DMA byte count,
just to make it that little bit harder...

Chris Maltby - Neology Ltd.  (chris@neology.oz, seismo!neology.oz!chris)