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 Crawford