bes@holin.ATT.COM (Bradley Smith) (08/10/89)
Ok here is the latest. first - the 'ld -r -o uipc.o /etc/lddrv/ifile.wind ...' didn't work something about can't allocate address second - catching the linesw for reads & writes didn't buy me much other than I could verify my address. now what I have gotten to work. By using nlist and loading the vaules via a boot program (right now they are hard coded) I can get at the wintty struct which is most likely defined as 'struct tty wintty[WINNUM];' where WINNUM=12. Further more I can look at all the tty elements. Now the interesting stuff. First I am currently only interested in input (so we don't block on reads, and can select on stdin). 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. 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. 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. 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. Anyone have an idea? Note: if one was to increase the number of windows, one would have to change wintty (ie patch wind.o so that it uses your address) and since it is an array of structures instead of a pointer, you have to patch actual .text segment -- Bradley Smith Computer Systems Offer Integration Laboratory AT&T Bell Labs, Holmdel, NJ 201-949-0090 att!holin!bes or bes@holin.ATT.COM
ford@cbmvax.UUCP (Michael "Ford" Ditto) (08/11/89)
In article <642@holin.ATT.COM> bes@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@amix.commodore.com - The Unix Programmer's Manual, ...!uunet!cbmvax!ditto 2nd Edition, June, 1972. ford@kenobi.commodore.com