Need more help on /etc/lddrv/wind.o

[Michael "Ford" Ditto]

In article <642 at holin.ATT.COM> bes at holin.ATT.COM (Bradley Smith) writes:
>In
>looking at Ditto's nkbd.c driver when it gets a char it ends up calling
>(*linesw[].l_input)(tp), which from looking at /etc/master, wind
>dosnot have.

The linesw (line discipline switch) entries are not parts of device
drivers such as "wind", they are pointers to the tty driver code
(line discipline) being used by a tty device.  Type "stty -a" and see
where it says "line = 0"; that means your tty device is using line
disclipline zero, the "normal Unix tty driver".  The l_input entry
for line discipline zero is "ttinput".

>  Also nkbd.c sticks the chars on the end tty->t_rbuf.c_ptr
>and has tp->t_rbuf.c_count count down via --.  This is backwards from
>the pty driver.

That is the way for a device driver to give characters to the line
discipline for input processing:  put then in rbuf.c_ptr[] and
decrement rbuf.c_count, and then call l_input(tp).  The pty driver
does it the same way (look at the write function for the master side,
which corresponds to keyboard input).

>Further more c_count also is 64 (as is c_size which
>is the buffer size) when I do selects and have typed chars in, ie.
>I have a loop that does a select for 5 seconds, and repeats this.
>The first time around I get select=0 (which it should) but then I
>type chars (with out a read) and select still is 0 and all the buffer
>address and counts haven't changed.

Those fields (in t_rbuf, the receive buffer) are only used for passing
characters from the driver to the line discipline input routine
(l_input).  The input routine will immediately take the bytes out of
t_rbuf and do whatever it does with them, resetting the t_rbuf fields so
that the driver can reuse them.

>Even though the nkbd.c driver has
>been called (debug messages in it). Also it appears that even
>if in the program there is a sleep(30); and I type chars in the wind
>driver sucks them up and puts them else where and I can't seem to
>find out where.

Line discipline zero moves the characters from the receive buffer to
the raw queue, doing echo at the same time if enabled.  In canonical
mode (ICANON), it checks for characters that would cause a waiting
process to wake up.  When such a character is input, it wakes up any
process blocked on a read, which then does "canonical processing",
copying the bytes from rawq to canq.  In "raw" mode (!ICANON) the
characters are directly copied to the canq.  Line disciplines other
than LDISC0 handle data in completely different ways, but this probably
isn't a concern for this application, since the only other discipline
for the Unix PC is "xt", the layers protocol driver, which should never
be used directly by a program.

>Anyone have an idea?

What you want for select is to look at t_canq.c_cc.  There might be
a problem when characters are typed and no process has tried to read
them, which is quite likely if a process is using select to decide
whether to read.  The canonical processing will not have been done
(since it is only done in read()), so canq will always be empty.
Select would have to call the function canon(tp) in that case in order
to force the canonical processing to happen.

By the way, the above method will work equally well on the window
driver, pty driver or serial driver.  It only needs to know the
(struct tty) for the device.  Theoretically, this is
cdevsw[major(dev)].d_ttys[minor(dev)], but the d_ttys field seems not
to be maintained by the Unix PC loadable driver system.

Note that the idea of putting select into the Unix PC kernel is a very
sleazy one.  Select needs to be supported by the kernel's tty subsystem
and each line discipline and each device driver to work properly.  It
is probably possible to get it mostly working in the limited sense
that is desired here, though.
-- 
					-=] Ford [=-

"The number of Unix installations	(In Real Life:  Mike Ditto)
has grown to 10, with more expected."	ditto at amix.commodore.com
- The Unix Programmer's Manual,		...!uunet!cbmvax!ditto
  2nd Edition, June, 1972.		ford at kenobi.commodore.com