Re: Sio & Puc memory mapped

On Sat, May 15, 2004 at 01:19:04AM +0400, Roman Kurakin wrote:
> 
> >>May I ask you to make some tests for me?
> >>
> >>We have a set of tests, which we use for testings of our async
> >>adapters. I add support for one of ours cards via puc(4)&uart(4)
> >>drivers. These tests works fine with patches for sio(4) driver (was
> >>tested with 5.2 sio), but fails with puc(4)&uart(4).
> >>
> >>I don't have any other cards supported by uart(4), so I can't test
> >>it by my self. If you have a time and ability, I'll send these tests
> >>for you.
> >>   
> >>
> >Why not just use sio?  It has been tested for hundreds if not thousands
> >of programmer hours in various versions over the last 16 years.  uart
> >fails even simple tests, and has low performance.
> >
> I second. Sio works just fine with mem-maped cards after small patch.

[detailed feedback has been sent privately to rik_at_]

With the following two changes/fixes to the test program, uart(4) passes
all tests:

<patch>
--- asytest.c~	Fri May 14 11:50:10 2004
+++ asytest.c	Sat May 15 11:31:03 2004
_at__at_ -152,6 +152,7 _at__at_
 		}
 
 		opt = chan[i].old_options;
+		cfmakeraw (&opt);
 		cfsetspeed (&opt, baud);
 		opt.c_cflag = CREAD | CS8;
 		opt.c_lflag &= ~ICANON;
_at__at_ -198,7 +199,7 _at__at_
 		for (c=chan; c<chan+MAXCHAN; ++c)
 			if (c->fd > 0) {
 				if (c->ready_to_transmit) {
-					s = write (c->fd, tbuf+it, IOSZ);
+					s = write (c->fd, tbuf+it, IOSZ-it);
 					if (s <= 0) {
 						if (s < 0) {
 							if (errno != EAGAIN)
</patch>

The first (the cfmakeraw() insertion) may be related to uart(4) not
setting proper defaults, but may also be related to uart(4) setting
different *valid* defaults. The second is a genuine test program bug
triggered by write() doing partial writes. This bug too may be the
result of uart(4) not setting the right defaults, but since the test
program doesn't assume complete writes the bug is primarily in the
test program by virtue of allowing partial writes.

In any way, it's very common for the simple test cases to not test
proper behaviour, but to actually test whether the behaviour is the
same as for sio(4) or not.  I have no doubt that uart(4) has more
flaws than I already know about, but the general negativity expressed
by bde_at_ in this case is FUD and in practice the test programs are as
much, if not more broken than uart(4) is.

FYI,

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel_at_xcllnt.net