brad@bradley.bradley.edu (Bradley E. Smith) (03/01/91)
Submitted-by: brad@bradley.bradley.edu (Bradley E. Smith)
Posting-number: Volume 1, Issue 13
Archive-name: uipc/part06
[ Here is the missing doc directory for the uipc code. Dave ]
# This is a shell archive. Remove anything before this line,
# then unpack it by saving it in a file and typing "sh file".
#
# Wrapped by brad on Sat Feb 23 09:04:57 CST 1991
# Contents: doc/ doc/README-FIRST doc/post1 doc/Read-pty doc/BUGS
# doc/Read-uipc
echo mkdir - doc
mkdir doc
chmod u=rwx,g=rx,o=rx doc
echo x - doc/README-FIRST
sed 's/^@//' > "doc/README-FIRST" <<'@//E*O*F doc/README-FIRST//'
File last updated: Tue Feb 12 21:07:09 CST 1991 - Bradley Smith
Currently at brad@bradley.bradley.edu
* CURRENT README FILE FOR MERGE PTY & SOCKET LIBRARY/DRIVER
This is a merged driver of the pty code (see Read-pty) and the socket
code (see Read-uipc) plus some inhancements.
This readme file will state what is new, how it works, what I know
doesn't work (because I haven't coded it) and so forth.
The pty driver is the same, I added one thing. This is to get the
major device number upon opening. This make easier for select
to work (more on this later). The reason for merging pty driver
is so that one can get at the structures easier. The pty driver
could be taken out and figured at load time, but this way I don't
have to worry about it. If I get enough complaints about this
I can remove the pty driver from the socket code.
The socket code is basically the same execpt for 2 more functions
which are select and sosetup, and a file called linesw.c
linesw.c is used for initialization, we reassign the linesw
functions of read, write and input so that we can check on
select function if it needs to be woken up.
sosetup allows me to set the major device number of /dev/window
which on my machine is 7, but might not be on yours.
Also it allows me to set the address of wintty which is used
to see if input is on one of the windows. RIGHT NOW THIS IS
A SECURITY HOLE, IF ONE CALLS THIS FUNCTION AND SETS THE
WRONG NUMBERS, WHO KNOWS WHAT WILL HAPPEN. I PLAN ON FIXING
THIS BUT THE MAIL I AM RECEIVING ON THIS PROMPTS TO SEND IT
OUT NOW. ONCE AGAIN THIS IS FOR DEVELOPEMENT!
select(2) has been added. and it works currenly only on the
read bitmask. I plan on added the write soon but mail....
anyways select works on the read side of the master (I tested
this), stdin of any window (I tested this), and of couse
and socket. Things I haven't tested are slave side of pty
(Code is there and should work, but you never know) and
/dev/tty00? (there is no code at all supporting this here)
and expansion card so I am not sure about anything other than
/dev/tty000) and /dev/ph? (same as /dev/tty000).
Also the timeout for select is a long for seconds. ie
long t;
t = 10;
ret = select(32, &readbt, &writebt, &excepbt, &t);
for timeout in 10 seconds.
There is a support directory that contains the program to be used on
startup, install will put it in /etc/daemons so at boot time it gets
done.
Also I have include a version of vtem (vt100 emulator) which uses
select on the master side of pty and stdin. This version uses less
system resources that the one posted which doesn't uses select but
uses non-blocking i/o instead.
NOTE: if select doesn't work on stdin or pty, usually it means that
the driver didn't load right.
MORE: I would like select to be able to use pipes....I will look
at it but if anyone has an idea on it now, please let me know.
EVEN MORE: It appears that on unloading the device driver that if you
switch windows (ie have more than one window open) it sometimes panics
on you. Also I have run it under the regular 'cc' (for those who don't
have 'gcc') and gcc version 1.31 (yes I need to get a more up to date
copy).
=====================================================================
Sun Aug 27 21:24:53 EDT 1989
UPDATE: select now works on read & write on window devices(stdin,stdout
if you are on /dev/w*), pty (master and slave side), named pipes
(haven't tried using pipe(2), maybe soon), and of couse sockets.
Note you still need the initialize program. If you unload the device
using the "/etc/lddrv/lddrv -dv pty" command, chances are you will
crash the machine, because programs like smgr, ph, wmgr have return
address via write,read,open,close calls that will return to non-valid
addresses. so I would not recommend it, the remove script reboots
the machine, which is the proper way.
Well it is off to other things for now, I am tried.
brad smith
===================================================================
The uipc code now has the select code from MGR....this means that
one can switch uipc stuff inplace of the pty code that come with
MGR.....All programs that use select must be recompiled.....this
is because I replace the select code in the kernel and the chances
that the syslocal call being the same is not good.....if you are
reading this file hopefully you got a patch file as well.
@//E*O*F doc/README-FIRST//
chmod u=rw,g=r,o=r doc/README-FIRST
echo x - doc/post1
sed 's/^@//' > "doc/post1" <<'@//E*O*F doc/post1//'
CALL FOR DISCUSSION
Topic: Serial line networking of unix-pc's.
As my efforts to produce a working socket driver for the
unix-pc are generating positive results (it works), The looming
question of how to interconnect machines is becomming more pertenant.
like many people, I bought a large machine and later a small machine
as a future parts doner, and getting the two of them to talk would be
right nice. I'm running a uucp network now, but I'd really like some
kind of packet base protocol. With the TCP driver taking shape, the
idea is becomming more attractive.
For myself, I would like to run a bus network around my house,
consisting of a single serial line. I will probably purchase a mac as
a game machine/graphics engine/word processor for my wife in the next
year or so, and I would like to pick up a nice printer, an maybe a
trailblazer. Also, I never want to buy a peripheral from apple! (nobody
has that much money)
So I'm figureing my network to be:
HARDWARE
1) a bi-directional bus network, or some kind of fault-tolerant ring
that can tell when a host goes down. No star networks. I only want to
have to deal with one port per machine, and I want to be able to splice
in devices.
2) RS232 or simular hardware speeds and voltage levels. ($$$)
3) hardware support for packet acceptance/rejection, and queueing of
data so that the machines don't die.
SOFTWARE
1) support for virtual circuits and datagrams, with out-of-band
facilities.
2) reasonable efficency with in packet overhead.
3) gateway/forwarding capability, for dealing with modems and printers.
This means machine addresses and ports.
4) virtual files, as in some kind of restricted NFS.
I think that some kind of minimal hardware support is going to be
required for speed, but I'd like to make that an option, so that poor
folks can use the existing RS232. I envision a card that watches the
net and screens packets against their address. I would also like at
least 16 bytes of buffer space with a timeout, to limit interrupts.
I'd also like to use an existing protocol, custom protocols are a drag
unless they catch on, even free ones. The two protocols that come to
mind are SLIP and Appletalk. SLIP would be in keeping with tradition,
but I'm worried about the overhead. I don't know anything about
Appletalk, but the fact that its built around a serial line suggests
that its optimized for speed. The fact that I'm looking at a mac also
makes Appletalk more desireable :-).
Also, Appletalk hardware is pretty close to what I'm looking for,
although I don't know much about it. Appletalk also supports some kind
of disk sharing that works over a serial line.
I will probably add the code for SLIP anyway, since much of the code
is free and available. I'm looking into a protocol developed at CMU
thats built around Appletalk, and if the code is free, I'll look into
adding that to, if only for my future mac.
So what does everybody think? I want to write something thats going to
be *used*, although I won't be charging for it. What are your needs? I
don't know diddly about hardware, so I would like to here from the
hardware guys regarding the interface. Optimally we would see the same
deal as the hard disk upgrade, namely a "lenny and gil do it yourself"
model and a "custom PAL on a special board for $$" version.
@//E*O*F doc/post1//
chmod u=rw,g=rw,o=rw doc/post1
echo x - doc/Read-pty
sed 's/^@//' > "doc/Read-pty" <<'@//E*O*F doc/Read-pty//'
README: Eric H. Herrin II
University of Kentucky Mathematical Sciences Laboratories
915 Patterson Office Tower
University of Kentucky
Lexington, KY 40506
eric@ms.uky.edu, ..!cbosgd!ukma!eric
Version 2.1
Thanks to
1. Mike "Ford" Ditto
kenobi!ford@crash.CTS.COM, ...!crash!kenobi!ford
for his bug fix in the ptyrelease routine.
2. Michael Bloom
mb@ttidca.tti.com
for his bug fix to the master read routine in the original driver.
I incorporated this fix and it seems to work fine.
This directory contains the PD pty driver for System V, modified for
use with the AT&T UnixPC or Convergent Technologies Safari 4 computers,
running Version 3.51 of the UNIX System V OS (it may also work on
earlier versions, but I have no way of verifying this). Anyone using
this driver should have no problems, but I will provide little support.
Questions should be sent to the above address, either with ground mail
or real (e-)mail.
This README is intended to mark the changes made to the PD pty driver to
satisfy the author's request. It was not easy or feasible to clearly mark
every change in the code, thus it was decided that an explanation of the
procedure would probably be enough. A brief introduction to UnixPC
device drivers is followed by the list of changes made. A couple of
hacks will also be explained.
NOTE: The #ifdef DEBUG statements use eprintf() instead of printf().
This puts any messages into the error icon's queue of system
errors (the icon is the !! icon at the top of the console).
UnixPC device drivers:
The UnixPC has a different kind of device driver from other
System V machines. They can be loaded while the machine is running or
at boot time, but are always linked into the OS while the kernel is
active. However nice this may be, there ARE some problems.
1. Loadable device drivers CANNOT communicate with one another.
That is, one driver cannot use a data structure defined in
another driver (IE. they are not in the same identifier
name space).
2. Conf.c doesn't exist, it is redone by the /etc/lddrv -av
program and relinked into the kernel. Thus, one can't
declare common structures this way.
Changes to the PD pty driver:
The following changes (hacks?) were made to the PD pty driver for
the purpose of making it usable on the UnixPC.
Problem 1 & 2 influenced me to try to make a single driver
(there were two, ptm and pts). How could one do this?
My solution (and I would be very interested if you can
think of a better one) was to create the slave devices
/dev/tty[p-z][0-f] with minor numbers 0-(PTYCNT/2-1) and
master devices /dev/pty[p-z][0-f] with minor numbers
(PTYCNT/2)-(PTYCNT-1). Major numbers of both types of devices
are the same. I can then simply define a macro to determine
whether the dev_t passed to the driver was a slave or master
pty. Once determined, I can perform the appropriate duties.
Also, it was more readable to merge the ptm and pts modules
into a single set of pty[open, close, ioctl, read, write]
routines. I added a release routine so that the kernel will
know the device has properly released if one deallocates
the driver.
Another modification was the addition of ptystate[], which
holds the MRWAIT, MWWAIT, MOPEN flags. This was necessary
because the original author insisted upon using 3 UNUSED
bits in the t_state field of the tty. The UnixPC does not
have any free bits here.
A check for TTIOW was added due to the fix by Michael
Bloom in the master section of the ptyread() routine. Note
his original fixes were for the original pty driver and
most of the changes were already incorporated into this driver.
Making alterations to the number of ptys, etc.
The number of ptys is defined in the file number-ptys.h. This
number should not exceed the maximum minor device number divided by
two. Ie. a maximum minor device number of 128 would allow
a maximum of 64 ptys. It is currently defined at only 32, but
I believe this is quite liberal, especially for a machine as
small as a 3b1. One could load the driver multiple times by
calling it a different name in the /etc/master file. One could
have the first 64 ptys with major number 10, the next 64 with
major number 11, etc. I think 64 should do fine for any reasonable
UNIX PC user (good grief, how would one use 64 ptys on a max
5 user machine? Better yet, how would one get 5 users on the
thing? Yuch!). At any rate, we don't use that many ptys on
a large system with lots of users.... so I really don't see this
as a problem.
Pty driver generation and installation procedure.
Put the number of ptys you want in the file number-ptys.h.
Type "make"
Type "/bin/sh MKflop"
Insert a floppy diskette.
Use the UA to install the diskette.
(you can skip the floppy part and simply run the Install script
in the same directory the pty.o object is located. But you
won't be able to uninstall it from the UA. There is a
Remove script to do this which you will have to run manually.)
Acknowledgement: I realize the usage of a single major device number is
a supreme hack, and I welcome any improvements/solutions. I do not assume
any responsibility for the changes I have made, nor do I imply any
liability on the part of the original author. I include a complete set
of {Install, Remove, etc, etc} scripts so that binary floppies may be
made to be installed by the UnixPC user agent. I do not assume any
responsibility for these either. I don't assume any responsibility for
anything even remotely related to this stuff.
Eric H. Herrin II
University of Kentucky Mathematical Sciences Laboratories
eric@ms.uky.edu, !cbosgd!ukma!eric
=======================Orignal pty README===============================
This is a pseudo tty driver for system V machines. It works very
similar to ptys on BSD, for instance emacs works fine. To install this
driver you will need to modify your `master' and `dfile' file which
contains your driver specifications. As these vary from machine to machine,
you will have to look up in your manual how to do that. Here is an example
for a sperry s5050 alias ncr tower 32 :
Add the following two lines to the driver description section in master:
pts 0 237 244 pts 0 0 28 32 0 tty
ptm 0 37 344 ptm 0 0 29 0 0
This says there are max 32 pts devices at major number 28 having associated
tty structures and 0 ptm devices having major number 29 with no associated
data. The number of ptm devices is not configurable, as this depends on the
number of pts's.
The following two lines go in the dfile:
pts 0 0 0
ptm 0 0 0
Probably you will also want to increase the NCLIST parameter.
If your configuration procedure is different, you must change the shell
script mkpty, which is used to create the device nodes in /dev.
The ptm devices (/dev/pty[p-z][0-9a-f]) are the controlling ones, everything
written there will show up at the associated pts device
(/dev/tty[p-z][0-9a-f]), as well as erverything which is written on the pts
device will show up on the ptm device. The pts side will accept the usual
termio ioctl calls. The master side is a bit different, as ioctl calls which
normally wait for output to drain flush output. The reason for this funny
behaviour is that otherwise the master side will hang. Also the master side
may be opened only once, further open calls will result in an EBUSY error.
@//E*O*F doc/Read-pty//
chmod u=rw,g=r,o=r doc/Read-pty
echo x - doc/BUGS
sed 's/^@//' > "doc/BUGS" <<'@//E*O*F doc/BUGS//'
For some reason, the system will sometimes crash when unloading the
driver. The cause is always "page fault in kernal". Syncing the disk appears
to prevent crashes, although I don't understand why. I have had good luck
using the following command sequence to unload the driver.
# cd /etc/lddrv
# sync;
# sync
# sync
# ./lddrv -d uipc
If anyone can shed light on why this works, I would love to hear it.
@//E*O*F doc/BUGS//
chmod u=rw,g=r,o=r doc/BUGS
echo x - doc/Read-uipc
sed 's/^@//' > "doc/Read-uipc" <<'@//E*O*F doc/Read-uipc//'
%Z%%M% %I% (Alex Crain) %G%
This package contains a device driver to implement BSD style
sockets on an AT&T 3b1. It is written for unix release 3.51 and
compiled using gcc, I don't know if it will work with a different
OS/compiler combination.
The code is directly derived from Berkeley kernel source, and
carries the Berkeley Copyright. I have added my own Copyright as well,
although I question its legality and I don't really much care what
happens to the code as long as nobody *sells* it (giving away is OK)
and my name stays on it.
The code is far from complete. At this writing, only the
AF_UNIX domain is supported, and SOCK_RAW is not implemented. Within
these restraints, the code implements the following system calls:
socket ()
bind ()
listen ()
accept ()
connect ()
socketpair ()
sockpipe ()
sendto ()
send ()
recvfrom ()
recv ()
setsockopt ()
getsockopt ()
The code has also not been adaquately tested and surely has
bugs. Since the interface routines are true system calls, the bugs
are likely to cause panics and other types of system crashes, so use
this driver at your own risk. Bug reports are encouraged, as are
enhancements and extensions within the realm of BSD compatability.
Send bug reports and patches to:
alex%nerwin.uucp@umbc3.umbc.edu
or
uunet!umbc3!nerwin!alex
The documentation is miserable, I will try to do better.
The system files are:
src/* - the c source files
uipc/* - the header files
lib/* - the user interface library
test/* - misc. test programs
Makefile- the global makefile
sysconfig.m4 - the system configuration file
To install the system, type 'make' in the root directory. This will
create two interesting files: src/uipc.o and lib/libuipc.a. uipc.o
goes in the /etc/lddrv directory. Add the following line to
/etc/master:
uipc 1100 000 000 uipc 0 0
and type:
cd /etc/lddrv; ./lddrv -av uipc
to load the driver. To make the driver load at boot tome, add "uipc"
to the file /etc/lddrv/drivers.
Put libuipc.a in /usr/lib, and copy the uipc directory to
/usr/include/uipc.
Again, please be aware that this code is delicate and likely
to cause crashes. If appropriate precautions are taken, however, it is
possible to avoid trashing your system. When testing device drivers
and code that uses them:
1) make sure that the system is quiet. Open files may be
damaged or lost when the kernel crashes. Do not test the driver when
uucico is running.
2) don't do two things at once. Get out of the editor before
testing new code.
3) type "sync" before running new code. This will flush the
kernels internal buffers. DO NOT run sync immediately after testing
new code, because if the kernel has trashed buffers, they will be
written to disk. Instead, run "ls" a few times to see if the system is
going to crash.
4) Do not install code that uses this package until it becomes
more stable. It might work for a while, but is likely to cause crashes
at in oppertune times.
The code is heavily protected with calls to panic(), so it is
doubtful that any major damage will result (I have crashed many times
while writing this and have yet to lose a file) if the precautions are
taken. The code will be better tested and documented soon, so if you
don't want to beta test, you can wait. In any case,
Enjoy
Alex Crain
@//E*O*F doc/Read-uipc//
chmod u=rw,g=rw,o=rw doc/Read-uipc
exit 0
--
David H. Brierley
Home: dave@galaxia.newport.ri.us; Work: dhb@quahog.ssd.ray.com
Send comp.sources.3b1 submissions to comp-sources-3b1@galaxia.newport.ri.us
%% Can I be excused, my brain is full. **