Fast serial (was: misc kernel patches... (mostly tty stuff))

["Nicholas S Castellano" <entropy@terminator.rs.itd.umich.edu>]

> ok!  but that still requires changes in MiNT.  for example currently it
>seems a 1K tty read gets _always_ translated into 1000 device reads of
>each one char, that just cant be fast no matter how good the driver is...
>and to get it real fast such a driver would also need a way to tell
>MiNT that it reads and writes bytes, not longs.  then it could get a
>RAW 1K read or write as that and just bcopy the data. (and also sleep
>gracefully when it waits for more than a few bytes to go over the port
>so it doesn't have to waste so much CPU time...)

The idea would be to have the drive bypass MiNT completely and twiddle
the iorec itself, to do the reads and writes.

The only thing at all difficult about doing this that i've noticed is
that the iorec elements seem to be misnamed and misdocumented; in
practice the head element seems to really be the tail and vice-versa.

> or things like TIOCCAR/CLOCAL, HUPCL.. they probably need some help
>from the kernel too.

I don't know what those are, but they look like maybe part of the
system V tty driver controls?  Of course if you want to support new
driver controls at least some of them will need to be in the kernel.

>>  I've been thinking recently
>> that most of my TOS 1.0 hacks in MiNT's rsconf() code should really be
>> in a standalone device driver as well (especially since that code
>> still doesn't work terribly well.)
>
> well either this, or just forget about those 1001 TOS bugs and tell
>people to use one of the serial port fix TSRs available, some of them
>now even work. :)

I agree, but I never found one that corrected the TOS 1.0 bug of not
being able to query the port speed.  (I think I found one that claimed
to do this but actually just caused spectacular crashes.) 

> and for a standalone modem driver rsconf (and iorec) would better just
>translate their parameters into device ioctls, right?

For the most part yes, but they could also do nice things like giving
real FIONREAD/FIONWRITE results for the serial port, allow Fselect()
on the port, etc.

>> In one of my conversations about the serial port with someone (I think
>> it was someone on this list) I was told that there was already a
>> driver along these lines that was mostly completed, but I haven't
>> heard anything about it since then.
>
> hmm i hope you don't mean me :) i only have a hacked serptch2 to
>replace buggy TOS routines, ([Bx]co*, Rcsonf, Ioctl...) but it doesn't
>know about MiNT.  the fast IO stuff i did for taylor uucp does it all
>itself... (and it has to `guess' the physical device with ttyname
>because i found no other way to get it from an fd)  but of course it
>could be useful for writing such a driver... its in tuu103d3.zoo on a.a,
>look at the diffs for sys2.c.

No, I was talking about a MiNT installed device for fast/better serial
port access, not a TSR.  I could go dig through my old mail and find
the refernce but it would probably be faster to just write the code
:-).

> other than that i only know of someone who seems to hate MiNT so much
>that he wrote a fast driver that tries to act like MiNT, but for TOS!
>(looks for Fopen ("u:\dev\modem1"..) and then handles Fread/Fwrite
>itself or so...  i guess if you could read all those maus news you'd
>sometimes just shake your head... :-)

I love it when people say they hate MiNT so they want to implement all
its functionality in TOS (e.g. they are effectively saying they want
to write their own MiNT :-)

--
entropy -- it's not just a good idea, it's the second law.
Personal mail:      entropy@gnu.ai.mit.edu
MiNT library mail:  entropy@terminator.rs.itd.umich.edu