1989 Summer USENIX AT&T UNIX pc BOF Minutes
Lenny Tropiano
lenny at icus.islp.ny.us
Mon Jun 19 13:35:45 AEST 1989
--------------------------------------------
1989 Summer USENIX: AT&T UNIX pc BOF Minutes
--------------------------------------------
Sponsored by ICUS Software Systems
Lenny Tropiano (lenny at icus.islp.ny.us)
Gil Kloepfer, Jr. (...icus!limbic!gil)
Tuesday, June 13, 1989
Hyatt Regency Hotel
Frederick Room
For all those who were unable to attend, I want to summarize the events so
the "net-community" can benefit from what was discussed. Granted I won't
be able to give explicit detailed account of what happened, because one, I
was running the whole thing (and speaking a lot of the time), and two, we
had probably one of the longest BOF's at the 1989 Summer USENIX. The BOF
was scheduled for the 6PM to 8PM slot, on Tuesday, June 13th (the first
slot for BOF's). As it turned out we needed slightly more time than what
I first anticipated. The meeting ran over till about 10:30PM, luckily no
one had the room reserved from 8PM to 10PM.
Some thanks are in order: first I want to thank all of those who attended.
Without your support and input, the BOF wouldn't have been what it turned
out to be. I want to thank specifically, Alex Crain (alex at umbc3.umbc.edu)
and Howard Motteler (motteler at umbc3.umbc.edu) for bringing their equipment
to the BOF so that we could use it afterwards. Thanks are in order for
Gil Kloepfer, Jr. (...!icus!limbic!gil) for speaking about the ICUS 2nd HD
plans, showing us some of the technical aspects, answering questions, and
taking some notes while I spoke. Marc Mengel (mmengel at cuuxb.att.com) of
AT&T deserves special thanks for giving us all some insight on the AT&T
support procedures, as well as some excellent technical information.
[=] What really did go on?
Well I introduced myself to the crowd at the BOF. I put up my fancy slides
on the overhead projector, made using "Paint Power." (Oooo...) I outlined
some topics that seemed to be of interest to the UNIX-pc community at
large, which were:
[I] Hardware Realm
a. Additional Hard Drives on the UNIX pc (ICUS plans,
John Milton's board)
b. What is meant by P5.1?
c. SCSI board work ("California Project")
d. "Mondo Combo" board (John Lydic's work)
e. 3.5" (800Kb) Floppy Drives
f. Voice Power Boards
g. IBM PC-bus bridge
h. Tape Drives
i. Packet Radio
j. "Cheap networking"
[II] Software Realm
a. Socket Library (Alex Crain)
b. Internetworking TCP/IP, SLIP
c. Security issues on the UNIX pc (lack thereof)
d. Things delaying FixDisk 2.0 (3.51c, 3.51d, etc..)
e. Various Mailers, Sendmail, smail, elm
f. UNIX pc Device Drivers
g. X Windows port
h. BSD UNIX port
i. SVR3.0 port
[III] Miscellaneous Realm
a. AT&T Support of the UNIX pc (or lack of it...)
b. Convergent Technologies & AT&T nostalgia
c. How do we stand as an "user group" than can support
this machine?
d. (800) Hotline experiences ...
I started the ball rolling by going through these topics, hopefully firing
up a means of discussion among the group, which had grown to 45 people by
that time. Putting Marc Mengel on the spot, I asked if he would start the
BOF off with a discussion on AT&T, from his professional point of view.
Marc spoke about the TIER system at AT&T, how one is greeted when calling
the AT&T HOTLINE, and the modes of travel for your ticket. Marc worked for
a while on the TIER 4 support team for the UNIX pc, and still on occasion
offers his assistance to the group (or shall we say person, still running
the UNIX pc dept.) He explains, that the NSSC TIER 1 (the normal engineer
that you'll speak with, unless the call is escalated) get rated on the how
fast they resolve the "ticket" they are working on, and how many they will
complete in one day. I'm sure some of you have been put through the NSSC
system where the engineer will close out a call, even though you aren't
completely satisfied; then you call back and start the complete cycle all
over again. Marc says, you'll just feeding them what they want, the best
recourse you have is to tell them you'll call them back, and agree on a
time before they close the ticket officially. Of course, the method which
your call escalates is when you call several times with the same problem,
or the ticket cannot be closed by the TIER 1 engineer. I mentioned that
I will sometimes, "confuse, dazzle, or bend the truth," after going in a
complete circle for quite some time. If I've been down the same path once
before, and I get the same answer to aid in engineer to close his call,
I will explicitly say that, "I've tried that several times, without any
good results." By this time, the call should be escalated to the higher
TIERs within AT&T. Of course, writing letters to the Data Systems group
president doesn't hurt. It generally gets results, he mentioned.
By this time, the group discussed porting BSD UNIX to the UNIX pc. Marc
mentioned that there are a lot of BSD-isms in the UNIX pc version of UNIX.
Among these were BSD 4.0 paging, SVR2.0, System III, SVR3.0 terminfo, etc.
In other words, the version of UNIX in the UNIX pc is a conglomeration of
a long history of UNIXs. More on UNIX ports to come ...
Marc is going to mail me some information he had when he was at the TIER 4
group for the UNIX pc: some different "panics," what to do about them,
etc. An example of a "panic" he mentioned was some sort of address fault
when the pc=0x150c (in 3.51) and 0x1494 (in 3.50). This actually turned
out to be a hardware change to the motherboard. Two capacitors added to
pins on the 68010 CPU solved the problem. This had the TIER 4 team going
nuts for quite some time. I started talking about the FixDisk 2.0, and
the rumors that were circulating. Basically I spoke about the problems we
were having with a bug in the tty driver causing clists to just be lost.
Marc mentioned how nasty that code was, and what it's original origin was:
the DZ-11 tty driver that everyone sees when learning about tty drivers.
Just as a side note, I am running a version of the kernel, UNIX3.51dD,
that is very stable and hasn't lost a clist yet. It looks like the new
FixDisk (2.0) will be moving on its way.
After Marc, I handed the floor over to Gil Kloepfer, Jr. There seemed to
be a big interest in the hardware modifications Gil and I worked on. Gil
explained the history behind the 2nd drive modification, what P5.1 really
is, and how the upgrade actually multiplexes the two hard drives. He had
a overhead slide of the schematic that we distribute with our plans. The
board that is built on a perfboard has a 5 chip count: 3 TTL chips, and 2
disk driver chips. No special PAL programming was necessary, which is
unlike the P5.1 4th select line field modification that Convergent had. He
explained what the board gave them, what was necessary, how much tech-
nical expertise was necessary, and how it compared with the effort that
John Milton has done. Since John Milton was unable to attend, Gil spoke
informally on the topic of the Mondo Combo board, since we heard him speak
at the Trenton Computer Festival a few months back. Unfortunately we were
unable to give any specifics on how things are progressing but it sparked
an interest nevertheless. Gil also spurred some interest in a serial port
idea, about doing most of the work at the hardware level, and keeping the
software drivers simple. The line discipline at the hardware level will
dramatically increase the performance on the serial lines.
A few attendees asked about tape drives. No one really had a good solution
on how to tackle the tape problem. The Floppy Tape is too slow, and does
not have the storage capacity it should. Writing drivers for QIC-40 tape
drives isn't an easy task. Maybe if the SCSI idea ever gets off the ground
that will be the way to go. Some mentioned the serial line tape backup. I
don't know of any vendors that sell such a device, but in theory, one
could write the data out to the serial port. Granted it would be slow,
even at 19.2K. Everyone considered doing the 3.5" floppy drive a step in
the right direction (as far as backups are concerned), and the hardware
implications are much simpler.
After Gil we moved into the "Software Realm," and the interest in Alex's
socket code that he wrote. Alex spoke about serial line networking, and
that he is going to release his socket driver library to the public. It
is purely beta, and he said, "it is assured to panic, one way or another."
Although Alex wanted to implement AppleTalk, he opted for SLIP since that
was the more popular protocol. For those interested in beta testing the
socket code, contact Alex at the University of Maryland in Baltimore
(alex at umbc3.umbc.edu).
X-windows was a popular topic of discussion, since a lot of the exhibition
this year was on the X-windows, Open Look(TM), and other graphical inter-
faces. Unfortunately X-windows is quite large, as many of the attendees
mentioned. Alex said maybe we can work on a small implementation of the
X-windows code, and not have to deal with the 50MB of source code. Again,
Alex's socket library will help in doing the networking stuff.
Some small discussions were brought up about how good GNU CC is, and how
it compares to the stock pcc-compiler. The majority of people agreed that
the GNU CC compiler was far superior, and it generated much more optimized
code over the stock compiler. Alex is working on getting GAS and GNU LD
working on the UNIX pc. We look forward to that in the future. Although
the GNU CC compiler generated better code, it also takes quite a bit more
time to compile and optimize (much to do with the binary size ~400K).
The most surprising topic of discussion came up when we all thought the BOF
was about to wind down. I knew about this previously, but was not really
at liberty to discuss the topic to anyone, unless it was to be publicly
known. A small company, AGA, Inc., and ASI, Inc. has bought the SVR3.0
$100,000 source code license from AT&T and is planning on working to port
to the, yes you've guessed it, UNIX pc. A team is being developed right
now to work on all aspects of the project including coding, maintaining,
etc. If anyone is sincerely interested, please mail a short letter telling
how you can help with this project. E-mail to svr3-port at icus.islp.ny.us,
this will automatically be forwarded to the proper people who are working
on developing this project.
Porting SVR3 seemed like an enormous and impossible project to undertake,
especially since no one had access to the UNIX pc source code, and to the
hardware specific code like the driver(s), for example. Then out of the
clear blue sky, a person from AT&T UNIX Source Licensing spoke up. He then
mentioned that he was fairly new to the Greensboro, NC group, but now that
he was there they would "rock and roll!" Most of the licensing group does
not know how to write one piece of code, he said. He, on the other hand,
has an engineering background. He owns a UNIX pc, and wants to see some-
thing come of it. His reasoning is that AT&T might be receptive to his
idea of releasing the UNIX pc source code to the proper licensees. Even
more important, he mentioned wthe possibility of an inexpensive way of
enabling us to be able to purchase the source product. The chatter didn't
stop, everyone was talking about the possibilities. Another road being
explored now is if we can convince AT&T that the source code for the UNIX
pc (3.51x) is of a lesser version than SVR3.0, then we should be able
under some provision in source licensing, to get the previous release. But
since the UNIX pc product wasn't developed from one particular release, it
might be hard to convince the right people. But since he wants to "rock-n
roll", we might have a good chance. Of course we intend to keep the SVR3
product (if it ever gets off the ground), compatible with the existing
UNIX pc software. Basically by keeping the binary compatibility, as well
as the loadable device driver scheme, the concerns about having the things
like the DOS-73 (dc73) driver, Voice Power (voice) driver, Ethernet, etc..
working, could still be maintained.
Well that's about it, hopefully we'll see you all there in January at the
1990 Winter USENIX in Washington, DC. I'm sure there were many other sub-
topics that came up. Hopefully the individuals who where there can add to
my summary. Again, thanks for making it what it was ...
--
Lenny Tropiano ICUS Software Systems [w] +1 (516) 589-7930
lenny at icus.islp.ny.us Telex; 154232428 ICUS [h] +1 (516) 968-8576
{ames,talcott,decuac,hombre,pacbell,sbcs}!icus!lenny attmail!icus!lenny
ICUS Software Systems -- PO Box 1; Islip Terrace, NY 11752
More information about the Comp.sys.att
mailing list