bill@ftp.COM (Bill Lampman) (10/20/88)
Hi, I'm trying to write a SLIP (serial line IP) 'driver' for SCO Xenix '286. I've already gotten the IP kernel code running and I'm able to get SLIP packets from the serial ports via 'cat < /dev/tty1a', but I need to have the data from the serial port available to the IP kernel code for demultiplexing and checksumming, etc. Does anyone know how I can access the serial line data without having a daemon running to read the data and then write it back to the kernel ? This scheme would cause way too much overhead. Any help/advice is welcome. Thanks in advance, Bill -- ------------------------------------------------------------------------------ Bill Lampman @ FTP Software UUCP: ...harvard!ftp!bill ARPA: bill@ftp.com ...sometimes the songs that we hear are just songs of our own...
dyer@arktouros.MIT.EDU (Steve Dyer) (10/21/88)
In article <385@ftp.COM> bill@ftp.COM (Bill Lampman) writes: >...I'm able to get SLIP packets from the serial ports via 'cat < /dev/tty1a', >but I need to have the data from the serial port available to the IP >kernel code for demultiplexing and checksumming, etc. Does anyone know >how I can access the serial line data without having a daemon running to >read the data and then write it back to the kernel ? This scheme would >cause way too much overhead. You want to define a new TTY line discipline which will make the bytes available to your IP input routine. This is what's done for SLIP under 4.xBSD, and there's no reason you shouldn't be able to do the same, if your IP layer is in the kernel. --- Steve Dyer dyer@arktouros.MIT.EDU dyer@spdcc.COM aka {harvard,husc6,ima,bbn,m2c,mipseast}!spdcc!dyer
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (10/21/88)
In article <7581@bloom-beacon.MIT.EDU> dyer@arktouros.MIT.EDU (Steve Dyer) writes: >In article <385@ftp.COM> bill@ftp.COM (Bill Lampman) writes: >>kernel code for demultiplexing and checksumming, etc. Does anyone know >>how I can access the serial line data without having a daemon running to >>read the data and then write it back to the kernel ? This scheme would > >You want to define a new TTY line discipline which will make the >bytes available to your IP input routine. This is what's done I think he is trying to avoid having or writing the tty driver source. Can a kernel routine call ttyopen() and ttyread()? Ar there any PD tty drivers for Xenix (or Microport)? -- Jon Zeeff Ann Arbor, MI umix!b-tech!zeeff zeeff@b-tech.ann-arbor.mi.us
dyer@arktouros.MIT.EDU (Steve Dyer) (10/21/88)
In article <4886@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >>You want to define a new TTY line discipline which will make the >>bytes available to your IP input routine. This is what's done > >I think he is trying to avoid having or writing the tty driver source. >Can a kernel routine call ttyopen() and ttyread()? Ar there any PD >tty drivers for Xenix (or Microport)? You don't need tty driver source to write a new line discipline. That's the whole purpose of line disciplines, after all. You write your line discipline, add the correct entries to the master file, and then build a new kernel. The ttyread and ttywrite routines are assuming transfers to/from user space, so won't work as you'd like. A line discipline (or a STREAMS module if/when we have STREAMS serial devices) is really the only way to go. Trying to do what you suggest is as hard, if not harder, than doing it right. --- Steve Dyer dyer@arktouros.MIT.EDU dyer@spdcc.COM aka {harvard,husc6,ima,bbn,m2c,mipseast}!spdcc!dyer
matt@oddjob.uchicago.edu (Matt Crawford) (10/22/88)
) >In article <385@ftp.COM> bill@ftp.COM (Bill Lampman) writes:
) >>kernel code for demultiplexing and checksumming, etc. Does anyone know
) >>how I can access the serial line data without having a daemon running to
) >>read the data and then write it back to the kernel ? This scheme would
[ two responses deleted ]
I think the answers I've seen are on the wrong track. I believe Bill
just needs to know how to have his driver put the received packet on the
input queue for the IP module. I don't know Xenix so I can't give an
exact answer, but in 4.[23] the device driver checks to see whether the
IP input queue is full and, if it isn't, places the new packet on the
queue and sets a bit or tickles a software interrupt so that the IP
module will examine its input queue in the near future. Look for macros
or functions with names like IF_ENQUEUE or schednetisr. (Then try to
guess how they work!)
Matt Crawforddyer@arktouros.MIT.EDU (Steve Dyer) (10/22/88)
In article <477@tank.uchicago.edu> matt@oddjob.uchicago.edu (Matt Crawford) writes: >I think the answers I've seen are on the wrong track. I believe Bill >just needs to know how to have his driver put the received packet on the >input queue for the IP module. >...in 4.[23] ... look for macros or functions with names like IF_ENQUEUE >or schednetisr. Since Bill is using FTP's own IP support in the XENIX kernel, I'd assume he'd know how his IP input routine works. The problem stems from viewing serial ports as entities whose data necessarily originates and ends with a user process reading and writing /dev/ttyMN, which is a reasonable assumption for anyone who hasn't addressed this problem before. Line disciplines allow a kernel programmer to "splice" into the TTY read/write/start/input routines and change the normal serial line behavior, including, in the case of SLIP, wresting control from user-level reads/writes and giving the control to the IP input and output modules in the kernel. You can be sure that if they had been using the new AT&T-free Berkeley code, they'd already have the SLIP code which uses line disciplines under 4.x. End of problem, almost, except for differences between 4.x and Sys V tty drivers, which at the line discipline level aren't many, and a lot of 4.3-mbuf- specificity which wouldn't apply to code which doesn't use mbufs. OK, that's a lot for an "almost", granted, but by examining net/if_sl.c you should get a feel for what routines need to comprise the line discipline switch table entry for SLIP under any flavor of UNIX and with any implementation of IP. --- Steve Dyer dyer@arktouros.MIT.EDU dyer@spdcc.COM aka {harvard,husc6,ima,bbn,m2c,mipseast}!spdcc!dyer
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (10/22/88)
In article <7601@bloom-beacon.MIT.EDU> dyer@arktouros.MIT.EDU (Steve Dyer) writes: >Various things about SLIP and IP in a Xenix kernel. If someone comes up with low cost or PD code to run SLIP efficiently on an otherwise tcp/ip less machine, I'd be most interested. Particularily if source for the SLIP driver is provided (since I'd really need to modify it to run slfp, a slip variant). The tcp/ip providers for '386 and '286 machines I've talked to have always responded with "What?" when I asked about slip. -- Jon Zeeff Ann Arbor, MI umix!b-tech!zeeff zeeff@b-tech.ann-arbor.mi.us