Path: sparky!uunet!sun-barr!cs.utexas.edu!qt.cs.utexas.edu!
zaphod.mps.ohio-state.edu!think.com!mintaka.lcs.mit.edu!ai-lab!zurich.ai.mit.edu!ara
From: a...@zurich.ai.mit.edu (Allan Adler)
Newsgroups: comp.unix.msdos
Subject: Public domain unix for PC's ?
Message-ID: <ARA.92Jan7231737@schwyz.ai.mit.edu>
Date: 8 Jan 92 04:17:37 GMT
Sender: n...@ai.mit.edu
Distribution: comp
Organization: M.I.T. Artificial Intelligence Lab.
Lines: 6
Is there one ? If so, where can I get it ?
Allan Adler
a...@altdorf.ai.mit.edu
Newsgroups: comp.unix.sysv386
Path: sparky!uunet!paladin.american.edu!darwin.sura.net!jvnc.net!yale.edu!
qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!bronze!
mosque.huji.ac.il!ury
From: u...@mosque.huji.ac.il (ury segal)
Subject: 386's UNIX kernel source
Message-ID: <1992Jan8.071839.14478@bronze.ucs.indiana.edu>
Sender: n...@bronze.ucs.indiana.edu (USENET News System)
Nntp-Posting-Host: mosque.huji.ac.il
Organization: Hebrew University of Jerusalem, Israel
Date: Wed, 8 Jan 92 07:18:39 GMT
Lines: 9
Does someone have (free) 386's UNIX kernel source ?
--
*******************************************************************************
* Ury Segal * Phone: Home: (02) 971187
* Distributed Computing Project * Lab: (02) 585762
* Dept. of Computer Science * E-mail:
* Hebrew University, Jerusalem, Israel * u...@cs.huji.ac.il
*******************************************************************************
Path: sparky!uunet!mcsun!uknet!icdoc!lmjm
From: l...@doc.ic.ac.uk (Lee M J McLoughlin)
Newsgroups: comp.unix.sysv386
Subject: Re: 386's UNIX kernel source
Message-ID: <LMJM.92Jan9173533@raquel.doc.ic.ac.uk>
Date: 9 Jan 92 17:35:33 GMT
References: <1992Jan8.071839.14478@bronze.ucs.indiana.edu>
Organization: Dept. of Computing, Imperial College, London. U.K.
Lines: 15
Nntp-Posting-Host: raquel.doc.ic.ac.uk
In-Reply-To: ury@mosque.huji.ac.il's message of 8 Jan 92 07:18:39 GMT
I can't say for sure but in the second Berkeley networking release
there appears to be enough source for unix and enough 386 specific
code to actually get a system up and running. Have a look in
src.doc.ic.ac.uk:unix/bsd-sources
ftp.uu.net:unix/bsd-sources
--
Lee McLoughlin. Phone: 071 589 5111 X 5085
Dept of Computing, Imperial College, Fax: 071 581 8024
180 Queens Gate, London, SW7 2BZ, UK. Email: L.McLough...@doc.ic.ac.uk
--
--
Lee McLoughlin. Phone: 071 589 5111 X 5085
Dept of Computing, Imperial College, Fax: 071 581 8024
180 Queens Gate, London, SW7 2BZ, UK. Email: L.McLough...@doc.ic.ac.uk
Newsgroups: comp.unix.msdos
Path: sparky!uunet!math.fu-berlin.de!unidui!du9ds3!veit
From: v...@du9ds3.uni-duisburg.de (Holger Veit)
Subject: Re: Public domain unix for PC's ?
References: <ARA.92Jan7231737@schwyz.ai.mit.edu>
<LMJM.92Jan9172952@raquel.doc.ic.ac.uk>
Date: 10 Jan 92 08:47:31 GMT
Distribution: comp
Reply-To: v...@du9ds3.uni-duisburg.de
Organization: Uni-Duisburg FB9 Datenverarbeitung
Sender: @unidui.uni-duisburg.de
Message-ID: <veit.695033251@du9ds3>
Lines: 34
In <LMJM.92Jan9172...@raquel.doc.ic.ac.uk> l...@doc.ic.ac.uk
(Lee M J McLoughlin) writes:
>I can't say for sure but in the second Berkeley networking release
>there appears to be enough source for unix and enough 386 specific
>code to actually get a system up and running. Have a look in
> src.doc.ic.ac.uk:unix/bsd-sources
> ftp.uu.net:unix/bsd-sources
>--
>--
>Lee McLoughlin. Phone: 071 589 5111 X 5085
>Dept of Computing, Imperial College, Fax: 071 581 8024
>180 Queens Gate, London, SW7 2BZ, UK. Email: L.McLough...@doc.ic.ac.uk
Some utilities like 'adb', 'vi', 'at', 'cron', 'grep' (!) 'pr', 'tail'
and others are missing in the BSD Networking Release 2. This is not a
problem at all, since one can often choose among different PD versions
for that (e.g. borrowing from MINIX, or GNU-FSF).
One vital missing file of the BSD NWR-2 is /sbin/init. Except this
and some device drivers one might like (SCSI support) it seems to be quite
complete to build a UNIX kernel (provided you find an existing compatible
BSD-unix to prepare the first bootable root file system on disk. The
reading of the articles 'Porting UNIX to the 386' in DrDobbs' Journal
(01/91-12/91) is strongly recommended.
BTW, has anyone a suited *available* /sbin/init source to complete the
distribution?
Holger
--
| | / Holger Veit | INTERNET: v...@du9ds3.uni-duisburg.de
|__| / University of Duisburg | BITNET: veit%du9ds3.uni-duisburg.de@UNIDO
| | / Dept. of Electr. Eng. | X.400: /S=veit /O=du9ds3 /P=uni-duisburg
| |/ Inst. f. Dataprocessing | /A=dbp /C=de
Path: sparky!uunet!mcsun!uknet!edcastle!aiai!richard
From: rich...@aiai.ed.ac.uk (Richard Tobin)
Newsgroups: comp.unix.sysv386
Subject: Re: 386's UNIX kernel source
Message-ID: <5936@skye.ed.ac.uk>
Date: 10 Jan 92 15:19:45 GMT
References: <1992Jan8.071839.14478@bronze.ucs.indiana.edu>
<LMJM.92Jan9173533@raquel.doc.ic.ac.uk>
Organization: AIAI, University of Edinburgh, Scotland
Lines: 31
In article <LMJM.92Jan9173...@raquel.doc.ic.ac.uk> l...@doc.ic.ac.uk
(Lee M J McLoughlin) writes:
>I can't say for sure but in the second Berkeley networking release
>there appears to be enough source for unix and enough 386 specific
>code to actually get a system up and running.
The following from kern_exec.c suggests otherwise:
execve(p, uap, retval)
register struct proc *p;
register struct args {
char *fname;
char **argp;
char **envp;
} *uap;
int *retval;
{
/*
* Body deleted.
*/
return (ENOSYS);
}
There are other similar functions. Also, the standalone stuff needed
for bootstrapping is incomplete.
-- Richard
--
Richard Tobin,
AI Applications Institute, R.To...@ed.ac.uk
Edinburgh University.
Newsgroups: comp.unix.sysv386
Path: sparky!uunet!uunet!revell
From: rev...@uunet.uu.net (James R Revell Jr)
Subject: Re: 386's UNIX kernel source
Message-ID: <1992Jan11.022438.25193@uunet.uu.net>
Reply-To: rev...@uunet.uu.net (James R Revell Jr)
Organization: UUNET Technologies Inc, Falls Church, VA
References: <1992Jan8.071839.14478@bronze.ucs.indiana.edu>
<LMJM.92Jan9173533@raquel.doc.ic.ac.uk>
Date: Sat, 11 Jan 1992 02:24:38 GMT
In article <LMJM.92Jan9173...@raquel.doc.ic.ac.uk> l...@doc.ic.ac.uk
(Lee M J McLoughlin) writes:
} I can't say for sure but in the second Berkeley networking release
} there appears to be enough source for unix and enough 386 specific
} code to actually get a system up and running. Have a look in
...
} ftp.uu.net:unix/bsd-sources
Use ftp.uu.net:/packages/bsd-sources
[Note, since I revealed the second networking tape was available at
that location one week ago we've logged over 100,000 transfers of
files in bsd-sources. Many of those were transfers of
bsd-sources.tar{,.Z} too. This is approximately 60% of all files ftp
over that time. Thanks for helping me with the burn in test of the
new ftp server :-) ]
--
James Revell sr uunet postmaster <rev...@uunet.uu.net> /8^{~
Path: sparky!uunet!wupost!darwin.sura.net!Sirius.dfn.de!fauern!unido!
mcsun!fuug!sics.se!seunet!kullmar!compuram!pgd
From: p...@compuram.bbt.se
Newsgroups: comp.unix.sysv386,comp.unix.internals
Subject: Re: 386's UNIX kernel source
Message-ID: <1992Jan11.082427.11910@compuram.bbt.se>
Date: 11 Jan 92 08:24:27 GMT
References: <5936@skye.ed.ac.uk>
Lines: 50
Richard Tobin (rich...@aiai.ed.ac.uk) writes:
: In article <LMJM.92Jan9173...@raquel.doc.ic.ac.uk> l...@doc.ic.ac.uk
(Lee M J McLoughlin) writes:
: >I can't say for sure but in the second Berkeley networking release
: >there appears to be enough source for unix and enough 386 specific
: >code to actually get a system up and running.
:
: The following from kern_exec.c suggests otherwise:
:
......
: /*
: * Body deleted.
: */
: return (ENOSYS);
: }
:
: There are other similar functions. Also, the standalone stuff needed
: for bootstrapping is incomplete.
Routines which are thus missing from the kernel are:
acct(), sysacct(), execve() with friends, physio(),
minphys(), rminit(), rmalloc(), rmfree(), ptrace(),
procxmt(), profil(), cinit(), getc(), q_to_p(),
ndqb(), ndflush(), putc(), b_to_q(), nextc(),
unputc(), bufinit(), bread(), breada(), bwrite(),
bdwrite(), bawrite(), brelse(), incore(), getblk(),
geteblk(), allocbuf(), getnewbuf(), biowait(), biodone()
I have looked them up in the unix v7 sources, and they amount to
approximately 800 lines of code.
Some I cannot find there. They are:
minphys(), rminit(), rmalloc(), rmfree(), procxmt(), nextc(),
unputc(), bufinit(), allocbuf(), getnewbuf()
Do they really containt AT&T code, or were they just kicked out "by
mistake"?
In any case, unless there are more surprises, it should not be too
hard to rewrite these routines. Many are quite straightforward.
Most routines contain 10-20 lines of code. One only 2.
Some are ridiculusly simple. In fact, I wonder how they can be
rewritten to not be identical with the AT&T ones.
Now, I wonder, are these routines really identical to the Unix v7
routines, or are they modified by the BSD people?
That is, would it be possible to plug in the V7 routines, modify them,
and get it working, without having seen the actual bsd routines?
--
Per Lindqvist
Internet: p...@compuram.bbt.se Fidonet: Per Lindqvist @ 2:201/332
Path: sparky!uunet!sun-barr!cronkite.Central.Sun.COM!newstop!eastapps!vergil!gsteckel
From: gstec...@vergil.East.Sun.COM (Geoff Steckel - Sun BOS Hardware CONTRACTOR)
Newsgroups: comp.unix.sysv386,comp.unix.internals
Subject: Re: 386's UNIX kernel source
Summary: re-invent ATT's wheel
Message-ID: <10349@eastapps.East.Sun.COM>
Date: 11 Jan 92 19:49:35 GMT
References: <5936@skye.ed.ac.uk> <1992Jan11.082427.11910@compuram.bbt.se>
Sender: n...@East.Sun.COM
Reply-To: gstec...@east.sun.com (Geoff Steckel - Sun BOS Hardware CONTRACTOR)
Followup-To: comp.unix.sysv386
Organization: Omnivore Technology, Newton, Mass. (617)332-9252
Lines: 45
In article <1992Jan11.082427.11...@compuram.bbt.se> p...@compuram.bbt.se writes:
>Richard Tobin (rich...@aiai.ed.ac.uk) writes:
>:
>: The following from kern_exec.c suggests otherwise:
>:
>......
>: /*
>: * Body deleted.
>: */
>: return (ENOSYS);
>: }
>Routines which are thus missing from the kernel are:
>[deleted]
>
>I have looked them up in the unix v7 sources, and they amount to
>approximately 800 lines of code.
[...]
>In any case, unless there are more surprises, it should not be too
>hard to rewrite these routines. Many are quite straightforward.
>Most routines contain 10-20 lines of code. One only 2.
>Some are ridiculusly simple. In fact, I wonder how they can be
>rewritten to not be identical with the AT&T ones.
Well, it depends... things like getc() and putc() would be hard
to make much different!
>Now, I wonder, are these routines really identical to the Unix v7
>routines, or are they modified by the BSD people?
They've been changed for things like VM and hashed buffer chains.
But not lots.
I'd do it myself (aside from minor things like a multi-year backup
of other projects & a need to keep clients happy...) but it certainly
wouldn't be `clean-room' - I've seen far too much of the ATT sources.
Ok, net-folk: one routine a person? it shouldn't take >too< long
to assemble a set of working versions. According to a posting from
UUNET, over 100,000 copies of the BSD files went out in one week!
SOMEbody must have a little time!
The interfaces are `well-defined' (:-) (:-) (:-)
regards,
geoff steckel (g...@wjh12.harvard.EDU)
(...!husc6!wjh12!omnivore!gws)
Disclaimer: I am not affiliated with Sun Microsystems, despite the From: line.
This posting is entirely the author's responsibility.
Newsgroups: comp.unix.sysv386,comp.unix.internals
Path: sparky!uunet!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!bronze!
mosque.huji.ac.il!ury
From: u...@mosque.huji.ac.il (ury segal)
Subject: Re: 386's UNIX kernel source
Message-ID: <1992Jan12.110903.26878@bronze.ucs.indiana.edu>
Sender: n...@bronze.ucs.indiana.edu (USENET News System)
Nntp-Posting-Host: mosque.huji.ac.il
Organization: Hebrew University of Jerusalem, Israel
References: <5936@skye.ed.ac.uk> <1992Jan11.082427.11910@compuram.bbt.se>
Date: Sun, 12 Jan 92 11:09:03 GMT
Lines: 62
In article <1992Jan11.082427.11...@compuram.bbt.se>, p...@compuram.bbt.se writes:
|> Richard Tobin (rich...@aiai.ed.ac.uk) writes:
|> : In article <LMJM.92Jan9173...@raquel.doc.ic.ac.uk> l...@doc.ic.ac.uk
(Lee M J McLoughlin) writes:
|> : >I can't say for sure but in the second Berkeley networking release
|> : >there appears to be enough source for unix and enough 386 specific
|> : >code to actually get a system up and running.
|> :
|> : The following from kern_exec.c suggests otherwise:
|> :
|> ......
|> : /*
|> : * Body deleted.
|> : */
|> : return (ENOSYS);
|> : }
|> :
|> : There are other similar functions. Also, the standalone stuff needed
|> : for bootstrapping is incomplete.
|>
|> Routines which are thus missing from the kernel are:
|> acct(), sysacct(), execve() with friends, physio(),
|> minphys(), rminit(), rmalloc(), rmfree(), ptrace(),
|> procxmt(), profil(), cinit(), getc(), q_to_p(),
|> ndqb(), ndflush(), putc(), b_to_q(), nextc(),
|> unputc(), bufinit(), bread(), breada(), bwrite(),
|> bdwrite(), bawrite(), brelse(), incore(), getblk(),
|> geteblk(), allocbuf(), getnewbuf(), biowait(), biodone()
|>
|> I have looked them up in the unix v7 sources, and they amount to
|> approximately 800 lines of code.
|> Some I cannot find there. They are:
|> minphys(), rminit(), rmalloc(), rmfree(), procxmt(), nextc(),
|> unputc(), bufinit(), allocbuf(), getnewbuf()
|> Do they really containt AT&T code, or were they just kicked out "by
|> mistake"?
|>
|> In any case, unless there are more surprises, it should not be too
|> hard to rewrite these routines. Many are quite straightforward.
|> Most routines contain 10-20 lines of code. One only 2.
|> Some are ridiculusly simple. In fact, I wonder how they can be
|> rewritten to not be identical with the AT&T ones.
|>
|> Now, I wonder, are these routines really identical to the Unix v7
|> routines, or are they modified by the BSD people?
|> That is, would it be possible to plug in the V7 routines, modify them,
|> and get it working, without having seen the actual bsd routines?
|>
Can someone work with me and add the code from reno or such, if legal ?
|> --
|> Per Lindqvist
|>
|> Internet: p...@compuram.bbt.se Fidonet: Per Lindqvist @ 2:201/332
--
*******************************************************************************
* Ury Segal * Phone: Home: (02) 971187
* Distributed Computing Project * Lab: (02) 585762
* Dept. of Computer Science * E-mail:
* Hebrew University, Jerusalem, Israel * u...@cs.huji.ac.il
*******************************************************************************
Newsgroups: comp.unix.sysv386,comp.unix.internals
Path: sparky!uunet!caen!sol.ctr.columbia.edu!bronze!mosque.huji.ac.il!ury
From: u...@mosque.huji.ac.il (ury segal)
Subject: Re: 386's UNIX kernel source
Message-ID: <1992Jan12.111831.27174@bronze.ucs.indiana.edu>
Sender: n...@bronze.ucs.indiana.edu (USENET News System)
Nntp-Posting-Host: mosque.huji.ac.il
Organization: Hebrew University of Jerusalem, Israel
References: <5936@skye.ed.ac.uk> <1992Jan11.082427.11910@compuram.bbt.se>
<1992Jan12.010507@eklektix.com>
Date: Sun, 12 Jan 92 11:18:31 GMT
Lines: 34
In article <1992Jan12.010...@eklektix.com>, r...@raven.eklektix.com (Dick Dunn) writes:
|> p...@compuram.bbt.se writes about the missing code in the BSD net 2 release:
|> >Routines which are thus missing from the kernel are:
|> [several dozen]
|> >I have looked them up in the unix v7 sources, and they amount to
|> >approximately 800 lines of code.
|> >Some I cannot find there. They are:
|> [ten more]
|>
|> [comparison with V7 background]
|> >Now, I wonder, are these routines really identical to the Unix v7
|> >routines, or are they modified by the BSD people?
|> >That is, would it be possible to plug in the V7 routines, modify them,
|> >and get it working, without having seen the actual bsd routines?
|>
|> It would probably be possible to start with the V7 routines--IF you could
|> use them. But remember that V7 source is also under AT&T license; you
|> can't distribute it. (Nor can you get a V7 source license any more.)
|>
We can use reno code.
|> How would you go about using V7 code?
|> --
|> Dick Dunn r...@raven.eklektix.com -or- raven!rcd Boulder, Colorado
|> ...Simpler is better.
--
*******************************************************************************
* Ury Segal * Phone: Home: (02) 971187
* Distributed Computing Project * Lab: (02) 585762
* Dept. of Computer Science * E-mail:
* Hebrew University, Jerusalem, Israel * u...@cs.huji.ac.il
*******************************************************************************
Path: sparky!uunet!auspex-gw!guy
From: g...@Auspex.COM (Guy Harris)
Newsgroups: comp.unix.sysv386,comp.unix.internals
Subject: Re: 386's UNIX kernel source
Message-ID: <11649@auspex-gw.auspex.com>
Date: 12 Jan 92 21:43:17 GMT
References: <5936@skye.ed.ac.uk> <1992Jan11.082427.11910@compuram.bbt.se>
<1992Jan12.110903.26878@bronze.ucs.indiana.edu>
Sender: n...@auspex-gw.auspex.com
Followup-To: comp.unix.sysv386
Organization: Auspex Systems, Santa Clara
Lines: 68
Nntp-Posting-Host: auspex.auspex.com
>|> Routines which are thus missing from the kernel are:
>|> acct(), sysacct(), execve() with friends, physio(),
>|> minphys(), rminit(), rmalloc(), rmfree(), ptrace(),
>|> procxmt(), profil(), cinit(), getc(), q_to_p(),
>|> ndqb(), ndflush(), putc(), b_to_q(), nextc(),
>|> unputc(), bufinit(), bread(), breada(), bwrite(),
>|> bdwrite(), bawrite(), brelse(), incore(), getblk(),
>|> geteblk(), allocbuf(), getnewbuf(), biowait(), biodone()
>Can someone work with me and add the code from reno or such, if legal ?
They probably could; too bad the Reno code in question *ISN'T* legal in
all cases. The Reno "vfs_bio.c" has what appears to be an "AT&T-free"
copyright notice, which would take care of:
bread(), breada(), bwrite(), bdwrite(), bawrite(), brelse(),
incore(), getblk(), geteblk(), getnewbuf(), biowait(),
biodone()
and the Reno "kern_exec.c" also has that notice, which takes care of:
execve() and company
and the reno "{hp300,tahoe}/ufs_machdep.c" also have that notice, which
gives Tahoe and HP 9000/3xx versions of:
allocbuf()
(although the VAX version doesn't have that notice) *IF*, in fact, they
really consider them AT&T-free.
However, the Reno "vm_swp.c" *doesn't* have that copyright notice, and
it contains:
physio(), minphys()
and the Reno "kern_acct.c" doesn't, either, and it contains:
acct(), sysacct()
and the Reno "subr_rmap.c" doesn't, and it contains:
rminit(), rmalloc(), rmfree()
and the Reno "sys_process.c" doesn't, and it contains:
ptrace(), procxmt()
and the Reno "kern_clock.c" doesn't, and it contains:
profil()
and the Reno "tty_subr.c" doesn't, and it contains:
getc(), q_to_b(), ndqb(), ndflush(), putc(), b_to_q(), nextc(),
unputc()
and the Reno "init_main.c" doesn't, and it contains:
cinit()
Also, the Reno "vaxstand/format.c" doesn't, and it contains:
bufinit()
unless the kernel in question has a "bufinit()" different from the one
in that particular *stand-alone* program, in which case Reno doesn't
appear to have such a routine in its kernel.
Path: sparky!uunet!mcsun!uknet!edcastle!aiai!richard
From: rich...@aiai.ed.ac.uk (Richard Tobin)
Newsgroups: comp.unix.sysv386,comp.unix.internals
Subject: Re: 386's UNIX kernel source
Message-ID: <5958@skye.ed.ac.uk>
Date: 13 Jan 92 14:18:10 GMT
References: <5936@skye.ed.ac.uk> <1992Jan11.082427.11910@compuram.bbt.se>
Organization: AIAI, University of Edinburgh, Scotland
Lines: 13
In article <1992Jan11.082427.11...@compuram.bbt.se> p...@compuram.bbt.se writes:
>In any case, unless there are more surprises, it should not be too
>hard to rewrite these routines.
Could someone from Berkeley tell us whether they are still working on
a complete detoxed version? Or has this aim been in some way
superseded by the BSDI release?
-- Richard
--
Richard Tobin,
AI Applications Institute, R.To...@ed.ac.uk
Edinburgh University.
Newsgroups: comp.unix.sysv386
Path: sparky!uunet!uunet!rick
From: r...@uunet.uu.net (Rick Adams)
Subject: Re: 386's UNIX kernel source
Message-ID: <1992Jan13.185201.15947@uunet.uu.net>
Summary: not att free
Sender: use...@uunet.uu.net (UseNet News)
Nntp-Posting-Host: rodan.uu.net
Organization: UUNET Communications Services
References: <5936@skye.ed.ac.uk> <1992Jan11.082427.11910@compuram.bbt.se>
<11649@auspex-gw.auspex.com>
Date: Mon, 13 Jan 1992 18:52:01 GMT
In article <11...@auspex-gw.auspex.com>, g...@Auspex.COM (Guy Harris) writes:
> >Can someone work with me and add the code from reno or such, if legal ?
>
> They probably could; too bad the Reno code in question *ISN'T* legal in
> all cases. The Reno "vfs_bio.c" has what appears to be an "AT&T-free"
> copyright notice, which would take care of:
>
> bread(), breada(), bwrite(), bdwrite(), bawrite(), brelse(),
> incore(), getblk(), geteblk(), getnewbuf(), biowait(),
> biodone()
>
> and the Reno "kern_exec.c" also has that notice, which takes care of:
>
> execve() and company
>
vfs_bio.c and kern_exec.c were INCORRECTLY MARKED on the reno release.
They do contain ATT code.
Thats also why they aren't on the NET2 release. They've been remarked.
--rick
Newsgroups: comp.unix.sysv386,comp.unix.internals
Path: sparky!uunet!sequent!muncher.sequent.com!jjb
From: j...@sequent.com
Subject: Re: 386's UNIX kernel source
References: <5936@skye.ed.ac.uk> <1992Jan11.082427.11910@compuram.bbt.se>
Message-ID: <1992Jan12.030302.16335@sequent.com>
Sender: n...@sequent.com (News on Muncher)
Organization: Sequent Computer Systems, Inc.
Date: Sun, 12 Jan 92 03:03:02 GMT
Lines: 34
In article <1992Jan11.082427.11...@compuram.bbt.se> p...@compuram.bbt.se writes:
>
>Routines which are thus missing from the kernel are...
>[Deleted list]
>Do they really containt AT&T code, or were they just kicked out "by
>mistake"...would it be possible to plug in the V7 routines, modify them,
>and get it working, without having seen the actual bsd routines?
If you have access to the V7 code, you have an AT&T source license, right?
In that case you can get a full Berkeley distribution and do whatever you
want with it; most of the routines you mention are not machine dependent.
(There may be licensing "levels" or issues I don't understand here - no
doubt some net.person will straighten me out if so.)
If you don't have a source license, then what you are proposing to do is,
well, Bad - fleshing out the mostly-complete unencumbered BSD distribution
through unlicensed access to the missing pieces.
If you want to do it yourself, without access to the AT&T sources, that
is interesting. The companies that clone PC BIOS code go to great
lengths to prevent their work from being "tainted". Certainly, nobody
who ever read or worked on the published IBM BIOS code would be allowed
to work on the clone, for obvious legal reasons.
By analogy, it seems to me that anybody who's done Unix kernel work over
the past 10 or 15 years is not a good candidate to recreate these
functions "from scratch". That rules out many of the best candidate
people to solve the problem.
Perhaps somebody from BSDI would be willing to comment on their strategy
for dealing with a potential legal assault from AT&T? What did they do
to ensure that their work was legally viewed as "original"?
--
Jeff Berkowitz, Sequent Computer Systems j...@sequent.com uunet!sequent!jjb
Newsgroups: comp.unix.sysv386,comp.unix.internals
Path: sparky!uunet!uunet!kolstad
From: kols...@uunet.uu.net (Rob Kolstad)
Subject: Re: 386's UNIX kernel source
Message-ID: <1992Jan14.204706.5662@uunet.uu.net>
Followup-To: comp.unix.sysv386
Summary: BSDI endeavors to do everything quite legally.
Sender: use...@uunet.uu.net (UseNet News)
Nntp-Posting-Host: rlavax.uu.net
Organization: UUNET Communications Services
References: <5936@skye.ed.ac.uk> <1992Jan11.082427.11910@compuram.bbt.se>
<1992Jan12.030302.16335@sequent.com>
Date: Tue, 14 Jan 1992 20:47:06 GMT
Last week, Jeff Berkowitz asked:
From: j...@sequent.com
Subject: Re: 386's UNIX kernel source
Message-ID: <1992Jan12.030302.16...@sequent.com>
Organization: Sequent Computer Systems, Inc.
Date: Sun, 12 Jan 92 03:03:02 GMT
Perhaps somebody from BSDI would be willing to comment on their
strategy for dealing with a potential legal assault from AT&T? What
did they do to ensure that their work was legally viewed as
"original"?
--
Jeff Berkowitz, Sequent Computer Systems j...@sequent.com uunet!sequent!jjb
BSDI has worked extensively with a computer law specialist to ensure that
all of our business dealings are strictly legal -- both within the letter
and the spirit of the law. It is inappropriate to discuss details of
these transactions in this public forum.
BSDI Program Manager,
Rob
--
====================================================================
/\ Rob Kolstad Berkeley Software Design, Inc.
/\/ \ kols...@bsdi.com 7759 Delmonico Drive