bes@holin.ATT.COM (Bradley Smith) (08/07/89)
Well this is to alert anyone working with Alex's socket code. Since there is no select(), I decided to write one, and have a working version for the read bitmask. I have also merged the pty code and socket code so that select (for the read side) now works for the master side of the pty (working on more). Now a question. I want select to work on the /dev/window as well (like stdin, stdout) but you can't access data in other loadable devices. I thought of find out what address the struct tty is at and looking at it that way. Does anyone have an idea? -- Bradley Smith Computer Systems Offer Integration Laboratory AT&T Bell Labs, Holmdel, NJ 201-949-0090 att!holin!bes or bes@holin.ATT.COM
alex@umbc3.UMBC.EDU (Alex S. Crain) (08/08/89)
In article <637@holin.ATT.COM> bes@holin.ATT.COM (Bradley Smith) writes: >Now a question. I want select to work on the /dev/window as well >(like stdin, stdout) but you can't access data in other loadable >devices. I thought of find out what address the struct tty is at >and looking at it that way. Does anyone have an idea? You can access data in loadable devices, *if you know the address*. One way of doing this is to link with /etc/lddrv/ifile.wind and assume that this info will not change. Another way would be to have uipcinit() read /etc/ldrv/ifile.wind (yuk). Since its reasonable to assume that wind.o will always be the first driver loaded, then there is no reason that the addresses should change, ever, so using that ifile is a reasonably good way of doing it. You could justify it by assuming that the window driver will someday be replaced, so this is only temporary :-). ld -r -o uipc.o /etc/lddrv/ifile.wind *.o should give you what you want. -- ################################# :alex. #Disclamer: Anyone who agrees # University of Maryland Baltimore County #with me deserves what they get.# alex@umbc3.umbc.edu ################################# alex%nerwin.UUCP@umbc3.umbc.edu
mmengel@cuuxb.ATT.COM (Marc W. Mengel) (08/08/89)
In article <637@holin.ATT.COM> bes@holin.ATT.COM (Bradley Smith) writes: >Now a question. I want select to work on the /dev/window as well >(like stdin, stdout) but you can't access data in other loadable >devices. I thought of find out what address the struct tty is at >and looking at it that way. Does anyone have an idea? Well, one way to do it is to define a line discipline, then you can change the line discipline routines when you init your socket code, and all the tty drivers will call your code. You should be able to put all the hooks you need in the line discipline, I think. >Bradley Smith -- Marc Mengel mmengel@cuuxb.att.com attmail!mmengel ...!{lll-crg|att}!cuuxb!mmengel
jbm@uncle.UUCP (John B. Milton) (08/09/89)
In article <2229@umbc3.UMBC.EDU> alex@umbc3.umbc.edu.UMBC.EDU (Alex S. Crain) writes: >In article <637@holin.ATT.COM> bes@holin.ATT.COM (Bradley Smith) writes: >>Now a question. I want select to work on the /dev/window as well >>(like stdin, stdout) but you can't access data in other loadable >>devices. I thought of find out what address the struct tty is at >>and looking at it that way. Does anyone have an idea? > You can access data in loadable devices, *if you know the address*. >One way of doing this is to link with /etc/lddrv/ifile.wind and assume that >this info will not change. Another way would be to have uipcinit() read >/etc/ldrv/ifile.wind (yuk). Since its reasonable to assume that wind.o >will always be the first driver loaded, then there is no reason that the >addresses should change, ever, so using that ifile is a reasonably good >way of doing it. You could justify it by assuming that the window driver >will someday be replaced, so this is only temporary :-). > > ld -r -o uipc.o /etc/lddrv/ifile.wind *.o > >should give you what you want. There is one minor problem. Everytime you change the version of the kernel you're using, each ifile.driver gets regenerated. The file /etc/.drvload does this: --- find . -name unix.sym ! -newer /unix -exec rm {} \; if [ ! -r unix.sym ] then echo creating unix.sym ./mkifile /unix unix.sym fi ---- and lddrv checks unix.sym to make sure it's older than the driver file So, you would have to at least regenerate the addresses everytime you change the kernel. John -- John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu (614) h:294-4823, w:785-1110; N8KSN, AMPR: 44.70.0.52; Don't FLAME, inform!
jcm@mtunb.ATT.COM (was-John McMillan) (08/09/89)
>>In article <637@holin.ATT.COM> bes@holin.ATT.COM (Bradley Smith) writes: >> Since its reasonable to assume that wind.o >>will always be the first driver loaded, then there is no reason that the >>addresses should change, ever, so using that ifile is a reasonably good >>way of doing it. ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ If we're going to enumerate the circumstances wherein the above view appears a bit "restricted": + A new wind.o is installed + A new kernel is installed (for some, a regular experience) + 'ktune' changes the kernel's size by at least a page + The system's RAM is switched from <=.5MB to >= 1MB, (or vice-versa -- Mega-YETCH !-) In other words, it's not a "reasonably good way of doing it" from some perspectives.
jbm@uncle.UUCP (John B. Milton) (08/12/89)
In article <2982@cuuxb.ATT.COM> mmengel@cuuxb.UUCP (Marc W. Mengel) writes: >In article <637@holin.ATT.COM> bes@holin.ATT.COM (Bradley Smith) writes: ... > you can change the line discipline routines when you init > your socket code, and all the tty drivers will call your > code. You should be able to put all the hooks you need > in the line discipline, I think. I once heard A LONG TIME AGO that the line discipline code on the UNIXpc is BUSTED and don't work. I have bumped into this stuff a lot, what can one do with a line discipline? Is this a sort of driver-filter? John -- John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu (614) h:294-4823, w:785-1110; N8KSN, AMPR: 44.70.0.52; Don't FLAME, inform!
ford@cbmvax.UUCP (Michael "Ford" Ditto) (08/19/89)
In article <2982@cuuxb.ATT.COM> mmengel@cuuxb.UUCP (Marc W. Mengel) writes: > you can change the line discipline routines when you init > your socket code, and all the tty drivers will call your > code. You should be able to put all the hooks you need > in the line discipline, I think. I don't know about "in the line discipline" since we don't have the ability to modify the line discipline code ... but perhaps with wrapper functions that go into linesw[0].l_* and call the old functions. If select had been designed into the kernel from the start there would be an l_select field in (struct linesw), since each line discipline has its own definition of whether a port is "ready" for I/O. In article <590@uncle.UUCP> jbm@uncle.UUCP (John B. Milton) writes: >I once heard A LONG TIME AGO that the line discipline code on the UNIXpc >is BUSTED and don't work. I have bumped into this stuff a lot, what can >one do with a line discipline? Is this a sort of driver-filter? What you heard about line disciplines not working on the Unix PC was probably me mentioning that /etc/lddrv/lddrv didn't seem to handle the "${module}in()" entry point under some conditions I didn't really determine. The "xt" driver that comes with the system goes in fine, but when I tried to install a line discipline called "sxt" lddrv got confused between sxtin() and sxtinit(). Actually, I now suspect that is is dependent on the order of the symbols in the driver -- fooin() must be before fooinit(). lddrv does a strncmp instead of strcmp for no apparrent reason, and the last symbol in the .o which is an initial substring of "fooinit" becomes the init function, even if it's "fooin". A line discipline is a set of routines that determine how the bytes sent through a tty device are interpreted/processed. For example, line discipline zero (the default) processes the erase/kill/eof/newline line editing characters, provides input echo, output delays, and CR/LF processing. In short, the line discipline is responsible for doing almost everything specified in termio(7). The c_line field in the termio structure determines which line discipline is in effect. On the Unix PC, there are two line disciplines available, 0 (the "normal Unix tty driver") and 1, the "xt" protocol discipline (if the "AT&T windowing utilities" package is installed). The xt line discipline is selected by the xt device driver when it is accessed by the "layers" program. It does none of the normal tty-driver types of things, it just speaks the xt packet protcol used by the Blit terminals, and multiplexes the data to/from the /dev/xt/* devices. On systems with the "shl" program, there is an "sxt" driver and line discipline to do the multiplexing used by that program. A typical use of the line discipline facility is to have an alternative tty driver with different (i.e. better) editing capability (on BSD unix, for example, you can use the "old" or "new" tty drivers, this is essentially the same idea). Another is to replace the "normal tty driver" processing with a protocol of some sort. On the SVR3 port to the Amiga, we have a TOPS-20 style tty driver and a SLIP (serial line IP) driver, both implemented as tty line disciplines. Type "stty line 4" and you get TOPS line editing, "stty line 0" switches back. On the Unix PC, it is probably reasonable for the select code only to work with line discipline zero, since it is unlikely that anyone will ever use anything else for a login session. -- -=] 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