🚀 go-pugleaf

My questions concern the Sun-3, Xinu7 version's implementation of putting
a character to the console device.

Could someone please explain the following??
In the ttyputc procedure, there is a call to ttyostart that enables tty
transmit interrupts. Enabling this allows the device to generate an
interrupt whenever it becomes idle. It should then be the device's 
responsibility to actually generate the interrupt which informs the 
interrupt dispatcher, Asm_ttyint for the Suns, to call the lower-level I/O
code in ttyoin. At least this is the way that Comer's, THE XINU APPROACH,
explains the process.

According to page 171 of the book, "starting interrupts is the only way 
upper-half output routines awaken lower-half routines to initiate
transfers. They DO NOT call them directly..."   Unfortunately (in terms of
confusion), the upper-half routine ttyostart does in fact call the lower-half
routine ttyoin directly. Thereby bypassing the interrupt dispatcher.
Why is this done????

Furthermore, the Sun-3, Xinu7 version of conf.c clearly indicates that the
console's *dviint(), and *dvoint() entries in the device switch table are
ioerr.  If the device then generates an interrupt, how can it use the
device switch table to determine the correct device driver to use?
The books conf.c file shows that the *dviint() and *dvoint() entries 
are ttyiin and ttyoin respectively. This is correct.

NOTE: I have looked at  Asm_ttyint in ttyint.s. This routine does check
to see if interrupts are pending, and if so, it does call ttyoin 
directly. Ignoring the device switch table enirely.


The big question is, why bypass the interrupt dispatcher???? And in doing
so, isnt it possible that ttyoin may start delivering characters to the
device when it isn't idle yet?????

thanks in advance

mike fortin