Garrett D'Amore writes:
> Solaris isn't used (that I'm aware of) on any platforms where this is
> likely to be an issue. Even if we did a MIPS port, the 16550 interface
> is still the most common way to talk to a serial port. I think this is
> largely true for PowerPC as well (though I've heard rumors of zs-ish
> ports on macs.)
Embedded PPC systems are very much different.
> ARM processors have a different variant, but we don't run on ARM. And
> I've not heard any rumors of any attempt to change that. (Though I'd
> _love_ to tackle a port to MIPS. There are some interesting MIPS parts
> out on the market, including a 16-core 1GHz-ish part that probably
> _needs_ an OS like Solaris to really shine.)
I wasn't thinking of ARM or MIPS. Sounds like fun for somebody. ;-}
> > I wouldn't want to have a robust 16550-ish implementation and a pile
> > of lousy other ones. That seems like a loss to me.
> >
>
> This would be true if we were looking at supporting a bunch of other
> UART-ish parts. We aren't, as far as I know. Even zs, as far as I
> know, is dead. I think se might still be alive for synchronous stuff,
> but I don't know that anyone us doing anything for async comm with it.
> In any case, the synchronous ports have different APIs, and I'm not
> ready to tackle them yet.
What about PowerQUICC, or whatever its successor is?
> > It's not so much an issue of chip support as it is an issue of
> > interfaces: how do we get the driver to turn this feature on when
> > needed?
> >
>
> Agreed. But for some things, like stop and start flow control
> characters, we have an API already, but we don't make use of the
> hardware features. That would be a good start, I think.
Maybe. I don't think it maps well into the "this is an interesting
character" problem.
> > With TCP/IP header compression in place, a packet with a single byte
> > in it -- a keystroke, say -- becomes a 7 byte message on the wire.
> > That easily fits in the FIFO, and there it rots until the timer kicks
> > and sends it upwards.
> >
>
> According to the 16550 datasheet, the timer should be 4 character
> times. Yes, its latency, but its small enough that even at 1200 baud
> you should never notice it.
>
> Go slower, and it becomes a problem. Because even interactive typing at
> 300 baud you will start to notice the incurred delays. Running a mouse
> at 300 baud, the delay would make it unusable. (Approximately 100
> milliseconds.) The solution to this problem that I'm using is to
> shorten the fifo trigger threshold to 1 character if the baud rate is
> low (currently slower than 1200). I can make this a tunable if there is
> value in it.
Hmm. OK. We do have special hacks ("immediate" mode) just for the
serial mouse case. The new driver should probably obey those.
> See above for an explanation of why I think this isn't a problem in my code.
>
> However, I think I've seen evidence of an attempt by old code to use a
> host-driven poll instead of the timeout interrupt. That would give long
> latencies, for sure. But no current driver for Solaris or NetBSD that
> I've looked at does this.
OK.
> We weren't. I consider the latency you're talking about to be
> uninteresting (4 character times) in the typical case, and avoidable (1
> character rx threshold trigger) in the few cases where it is interesting.
If we're only talking about 4 character times on all the hardware
you're planning to support, then I agree it shouldn't be an issue.
--
James Carlson, KISS Network <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
