fortin@tut.cis.ohio-state.edu (Micheal Fortin) (05/21/88)
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
comer@PURDUE.EDU (Douglas Comer) (05/23/88)
Mike, All hardware is different. In the ideal world, we want to separate upper and lower halves so the upper half deals only with user prcoesses and the lower half deals only with hardware. However, on the SUN, the hardware does not generate an interrupt when enabled, so the upper half must take more explicit action to start the device. In fact, the SUN may not use the real tty hardware at all -- it may direct output to the bit-mapped screen (in which case there is no interrupt...). As for bypassing the the device switch table, I think you overlooked something. Even in the early versions of Xinu, the iint and oint entries in the device switch table were consulted at system startup and then stored in the intmap table that gets used by the interrupt dispatcher. The reason is simple -- it's too inefficient to index the device switch table on every interrupt. Cheers, Doug
fortin@tut.cis.ohio-state.edu (Micheal Fortin) (05/24/88)
In article <8805231449.AA09097@merlin.cs.purdue.edu> comer@PURDUE.EDU (Douglas Comer) writes: > > As for bypassing the the device switch table, I think you >overlooked something. Even in the early versions of Xinu, the >iint and oint entries in the device switch table were consulted >at system startup and then stored in the intmap table that >gets used by the interrupt dispatcher. The reason is simple -- >it's too inefficient to index the device switch table on every >interrupt. > >Doug Yes, it is a good idea to consult the device switch table only at start up and then storing the info in the intmap table. But the Sun 3 implementation of Xinu7 has somehow gotten by without the use of the intmap table. ( Probably because each device has its own interrupt mechanism, instead of having one interrupt mechanism for all I/O like the book has) Even if there was an intmap table in use, it still could not have consulted the device switch table for the necessary interrupt dispatcher information, because the device switch table doesnt contain the correct entries. Anyway, thanks for the information concerning these matters. mike