From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.unix.bsd
Subject: Re: Catch What They're Saying About Us...
Date: 4 Oct 92 21:44:04 GMT
Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
NNTP-Posting-Host: 128.3.112.15

(As an aside, I should note that I am consistently appalled at what
seem to me to be misunderstandings on all sides.  I will also note that
I am not on the "BSDI side", nor the "Jolitz side", nor the "CSRG
side".  If I am on any side at all, it is "my side" or the "LBL side".
The intersection of any two "sides"'s goals tends to be quite large,
which may be confusing.  Remember that *everyone* is doing what they
think best.  We just have different perspectives, and sometimes
different goals.  LBL's ultimate goal is research---in our particular
case, network research.)

In article <19ta0nINNj2q@agate.berkeley.edu> wjolitz@soda.berkeley.edu
(William F. Jolitz) writes:
>[BSDI] have even received Chris Torek's sparc code, paid for by the taxpayers,
>which has not been made available to others despite repeated requests,
>and are currently attempting to make money off of it ...

In article <1a9frdINNijp@usenet.INS.CWRU.Edu> chet@odin.ins.cwru.edu
(Chet Ramey) writes:
>Oh, please.  This has come up before on comp.unix.bsd.  BSDI made an
>arrangement with LBL, who owns the code.  Whether it was a licensing
>agreement or a code exchange, I don't know, but neither BSDI nor Chris
>can make it available without the consent of LBL.

Hmm... where to begin... well, none of this is entirely wrong.  BSDI
have some code I wrote.  On the other hand, a later version of the same
code is on the 4.4BSD alpha tape.  As far as I know (which is not very
far: I just write the stuff; others keep tabs on distribution :-) ---
actually that is not quite right either; see below), BSDI are not
trying to market the SPARC code itself.  (I cannot say they have no
physical access to it; indeed, without documentation they must have had
to examine at least some of it in order to make use of the generic code
on the PC and write their own PC-specific code.  Again, see below.)
Meanwhile, we are getting equipment from BSDI.

The particular code BSDI have is a preliminary framework for device
configuration, along with a machine-independent SCSI disk driver based
on the old 4.3-reno HP-specific sd.c.  I have been holding off on
general release of this autoconfiguration framework for two basic
reasons.  First, it is still fairly "early" code, and has undergone
several revisions.  I personally dislike giving out code I know is not
yet "right": it takes too much time and energy to remember who has it,
and send updates and keep everyone working on the same code.  Some
things override this, like getting it tested on a second platform or
the 4.4BSD alpha release.  Second, the code was quite difficult to
use.  In particular, the old kernel configuration program ("config")
did not produce what the new code demanded.  Until a bit over a week
ago, we did not have a working "config", and built Makefiles, ioconf.c
files, and so forth "by hand".  The contents of ioconf.c were (and
still are, for that matter) described nowhere.

I still have no documentation for the new system, and the 4.4BSD alpha
tape does not have the new config (which is, incidentally, quite
incompatible with the old one at the kernel interface---the input
syntax should be familiar, though).  I am working on the documents, and
plan to release the code itself when this is done.  (I think it will
help with configuring under EISA, for instance---but someone who
actually understands the PC will have to convert all existing drivers
first.)  I have many other tasks as well, though, and refuse to set a
specific date for completion: I simply do not know when it will be
ready.

In summary: BSDI do have some LBL code, but they got it from LBL, not
CSRG.  BSDI made some kind of exchange deal with LBL, similar to
previous deals LBL have had with HP and Sun.  I have no details (I do
not make these deals), but I know it gets us equipment with which to
conduct research, and it gets them "incidentals" (such as code) that we
need to produce to run the equipment in order to conduct research.
Anyone can do this: just find some equipment we need, with some
incidentals you need, and start dealing.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
Newsgroups: comp.unix.bsd