Newsgroups: comp.os.linux.development
Path: gmd.de!xlink.net!howland.reston.ans.net!sol.ctr.columbia.edu!
news.kei.com!news.byu.edu!news.provo.novell.com!usenet
From: jdsm...@novell.com (J. Douglas Smith)
Subject: Status of the NET-2 port
Message-ID: <CCoyIz.9pL@Provo.Novell.COM>
Sender: use...@Provo.Novell.COM (USENET News)
Nntp-Posting-Host: bugs.npd.provo.novell.com
Reply-To: jdsm...@novell.com
Organization: Novell, Inc.
Date: Wed, 1 Sep 1993 20:06:35 GMT
Lines: 6
Can anyone tell me about the status of the BSD NET-2 tape port?
--
Doug Smith Internet: jdsm...@novell.com
Novell, INC. Phone: (801) 429-7324
Path: gmd.de!Germany.EU.net!mcsun!uunet!noc.near.net!howland.reston.ans.net!
xlink.net!subnet.sub.net!smurf.sub.org!smurf.sub.org!not-for-mail
From: urli...@smurf.sub.org (Matthias Urlichs)
Newsgroups: comp.os.linux.development
Subject: Re: Status of the NET-2 port
Date: 6 Sep 1993 09:46:39 +0200
Organization: Smurf-O-Box, Nuernberg, FRG
Lines: 34
Message-ID: <26epsv$1gc@smurf.sub.org>
References: <CCoyIz.9pL@provo.novell.com>
NNTP-Posting-Host: localhost
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
In comp.os.linux.development, article <CCoyIz....@provo.novell.com>,
jdsm...@novell.com writes:
> Can anyone tell me about the status of the BSD NET-2 tape port?
>
Hmm... what exactly are you talking about?
I know of one port of the BSD networking code to Linux, done by me.
Right now it is ugly, unfinished, and blocks interrupts for too long at
times. But it works. There are no Ethernet drivers except for WD8013;
SLIP is there, and BSDish utilities like slattach and traceroute compile
and run out of the box (almost), and you get a few other BSD goodies,
mostly related to TCP, which the Linux networking code doesn't (yet)
have.
If you're seriously(!) interested in looking at it, wait until next week;
I'll upload a complete set of sources to ftp.ira.uka.de, directory
/pub/systems/linux/netbsd or thereabouts, this weekend. Currently there's
a set of patches there which people have been having difficulties with.
Specifically, the code needs more drivers and better interrupt latency,
the packetfilter interface has to be LINUXified, netstat should be redone,
and a few other things.
Note that I'm not competing with the people who work on the Net-2 effort.
We simply have different priorities; they want to keep BSD code out of the
kernel because of possible copyright problems (the USL lawsuit isn't dead
yet), I want to use working code instead of spending the (essentially
duplicate) effort to recreate a fully-featured TCP/IP stack.
As usual, your mileage may vary.
--
Matthias Urlichs -- urli...@smurf.sub.org -- Phone: NONE; use email or lose.
Schleiermacherstrasse 12 -- 90491 Nuernberg -- Germany || Linux+Mac Consulting
Newsgroups: comp.os.linux.development
Path: gmd.de!newsserver.jvnc.net!yale.edu!nigel.msen.com!caen!batcomputer!
munnari.oz.au!metro!dmssyd.syd.dms.CSIRO.AU!its.csiro.au!mel.dit.csiro.au!
squid.mel.dit.CSIRO.AU!smart
From: sm...@squid.mel.dit.CSIRO.AU (Robert Smart)
Subject: Re: Status of the NET-2 port
Message-ID: <1993Sep10.002132.13102@mel.dit.csiro.au>
Sender: n...@mel.dit.csiro.au
Organization: Linux Users Victoria
References: <CCoyIz.9pL@provo.novell.com> <26epsv$1gc@smurf.sub.org>
Date: Fri, 10 Sep 93 00:21:32 GMT
Lines: 41
In article <26epsv$...@smurf.sub.org> urli...@smurf.sub.org (Matthias Urlichs)
writes:
>Note that I'm not competing with the people who work on the Net-2 effort.
>We simply have different priorities; they want to keep BSD code out of the
>kernel because of possible copyright problems (the USL lawsuit isn't dead
>yet), I want to use working code instead of spending the (essentially
>duplicate) effort to recreate a fully-featured TCP/IP stack.
The USL lawsuit is very dead - they're only arguing about how much
compensation UC should get for being maligned. If Linux could
be organized internally so that it could easily track networking
developments from Berkeley it would be a big plus. For example
you would then get:
1. Multicast.
2. CLNP (OSI connectionless protocol and one of the contenders for
the next generation of IP).
3. All the experiments with contenders for the new IP are being done
in a BSD context.
4. Low level support for lots of networking devices: ethernet, token
ring, FDDI, ISDN, ATM/BISDN, etc...
5. Network debugging tools.
We don't want to have to duplicate all this work.
I realise that the (Linux-)NET-2 release is designed to fit into
the Linux kernel. I realise that integrating BSD stuff is a pain.
The final decision has to come from Linus (and I'll bet he doesn't
want to drop work done by people who are particularly friendly
to Linux). It would be really nice if the people who've worked on
Linux Net-2 would say to Linus "We've learnt a lot and won't be
upset if you change again".
I fear that this has a nasty potential to fragment the Linux software
development. What worries me even more is that I could be forced to
leave Linux to run one of the BSD derivatives for practical reasons.
Bob Smart
Newsgroups: comp.os.linux.development
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!europa.eng.gtefsd.com!
uunet!super!becker
From: bec...@super.org (Donald J. Becker)
Subject: Re: Status of the NET-2 port
Message-ID: <1993Sep10.033246.28836@super.org>
Sender: n...@super.org (USENET News System)
Nntp-Posting-Host: descartes
Organization: IDA Supercomputing Research Center
References: <CCoyIz.9pL@provo.novell.com> <26epsv$1gc@smurf.sub.org>
<1993Sep10.002132.13102@mel.dit.csiro.au>
Date: Fri, 10 Sep 1993 03:32:46 GMT
Lines: 88
In article <1993Sep10.002132.13...@mel.dit.csiro.au>,
Robert Smart <sm...@squid.mel.dit.CSIRO.AU> wrote:
>In article <26epsv$...@smurf.sub.org> urli...@smurf.sub.org (Matthias Urlichs)
writes:
>>Note that I'm not competing with the people who work on the Net-2 effort.
>>We simply have different priorities; they want to keep BSD code out of the
>>kernel because of possible copyright problems (the USL lawsuit isn't dead
>>yet), I want to use working code instead of spending the (essentially
>>duplicate) effort to recreate a fully-featured TCP/IP stack.
This is what is meant by a "chilling effect", no one is willing to
pick up software that has a questionable legal status. And if the suit
goes the wrong way, you "knew, or should have known, that the code was
the intellectual property of <X>, and sought {unfair advantage},{to
dilute it's competitive value to <X>},{appropriate the item for your
own gain}". Then it starts looking like a criminal rather than
strictly civil matter.
>The USL lawsuit is very dead - they're only arguing about how much
>compensation UC should get for being maligned. If Linux could
>be organized internally so that it could easily track networking
>developments from Berkeley it would be a big plus. For example
>you would then get:
...
> 4. Low level support for lots of networking devices: ethernet, token
> ring, FDDI, ISDN, ATM/BISDN, etc...
I don't that this would necessarily be true.
>I realise that the (Linux-)NET-2 release is designed to fit into
>the Linux kernel. I realise that integrating BSD stuff is a pain.
>The final decision has to come from Linus (and I'll bet he doesn't
>want to drop work done by people who are particularly friendly
>to Linux). It would be really nice if the people who've worked on
>Linux Net-2 would say to Linus "We've learnt a lot and won't be
>upset if you change again".
I fall on both sides of this issue. I've put a _lot_ of effort into
the low levels of Linux networking, as almost all of the device-level
code was written by me. I would be very disappointed to see that
thrown away. I think many users would be disappointed as well -- the
ethercard drivers have been very solid, and going to BSD code would
mean dropping support for most of the not-quite-clone ethercards that
many Linux users have.
On the other hand, I see the not yet released "Net-2e" development
picking up significant parts of the BSD code, and I can't help
wondering what their goals really are. I see little difference
between having 1/3 of the code being from BSD with the existing
networking code changed to fit it (e.g. changed from sk_buffs to
mbufs), and 9/10 of being from BSD with only a new Linux kernel interface.
Coupled with this is my frustration at the way new bugs were introduced
with "Net-2", and then "development team" abandoned the code with the
promise "everything will be fixed when we come out with yet another
completely new structure". I feel hamstrung, because any improvement
or bug fix I make is destined to be swept away. I've been working on
an IP "fast-path" (to recover the significant drop in performance
going to "Net-2") and constant-expected-time fragment reassembly based
on Clark's algorithm. I'm not going to release these, or even keep
working on them, if they are only going to be in for a kernel
patchlevel or two. The same holds true for changing the device drivers
to be real devices, allocating low-memory buffers for DMA, and
implementing promiscuous and multicast modes -- these are trivial but
not worth doing if they will be immediately discarded.
Even if the USL lawsuit didn't exist, I think it's a good thing that
we are doing a publically-available networking implementation separate
and distinct from BSD. BSD has historic cruft, and most of the design
decisions date from a far different era and are ripe to be
revisited. A notable example is the use of 'mbufs', a structure that
is at the core of BSD networking. It was designed to hold packets as
a linked list of protocol headers and data pages. This was a good
idea in the days of microcoded machines with complex addressing modes,
short pipelines, and very small memories. On modern machines they are
slower than storing always storing the packet linearly. (Would
someone care to comment on how many times 'mpullup()' occurs in BSD,
and how expensive it is?)
Reading back over this letter I'm beginning to wonder if it's a good
time to join Ross.
--
Donald Becker bec...@super.org
IDA Supercomputing Research Center
17100 Science Drive, Bowie MD 20715 301-805-7482
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!vixen.cso.uiuc.edu!
sdd.hp.com!cs.utexas.edu!uunet!caen!usenet.coe.montana.edu!
bsd.coe.montana.edu!nate
From: n...@bsd.coe.montana.edu (Nate Williams)
Newsgroups: comp.os.linux.development
Subject: Re: Status of the NET-2 port
Date: 10 Sep 1993 07:19:17 GMT
Organization: Montana Stateu University, Bozeman MT
Lines: 54
Message-ID: <26p9pl$1rp@pdq.coe.montana.edu>
References: <CCoyIz.9pL@provo.novell.com> <26epsv$1gc@smurf.sub.org>
<1993Sep10.002132.13102@mel.dit.csiro.au> <1993Sep10.033246.28836@super.org>
NNTP-Posting-Host: bsd.coe.montana.edu
In article <1993Sep10.033246.28...@super.org>,
Donald J. Becker <bec...@super.org> wrote:
>BSD has historic cruft, and most of the design
>decisions date from a far different era and are ripe to be
>revisited.
Berkeley networking code has been re-written multiple times, and
is now considered 'the standard' upon all other networking code
is based upon.
>A notable example is the use of 'mbufs', a structure that
>is at the core of BSD networking. It was designed to hold packets as
>a linked list of protocol headers and data pages. This was a good
>idea in the days of microcoded machines with complex addressing modes,
>short pipelines, and very small memories. On modern machines they are
>slower than storing always storing the packet linearly. (Would
>someone care to comment on how many times 'mpullup()' occurs in BSD,
>and how expensive it is?)
Hmm, that may be the case, but I'll bet you dollars to donuts that it'll
be awhile before the Linux networking code (not BSD Net/2 code) can
saturate an ethernet. Not bad for *slow* code, is it?
I recommend taking a bit of the Linux attitude which seems to have been
completely lost in the BSD groups. I would rather have something that
works good-enough instead of something that is perfect when having
something perfect is going to take an un-known amount of time, and
something that is good-enough is available today (or soon).
A good example of this in Linux was the original shared libraries.
People were able to use the (non-optimal) shared library packages
because they needed them. Because they were non-optimal, they were
modified (which caused the users grief, but you didn't *have* to
upgrade). Today, they are fairly well done.
Now, in the BSD camp (of which I am acutely aware of), we have been
arguing about shared libraries for a long time, when versions similar to
the old Linux shared libraries, and even a version similar to the
current versions have been available for a long time. Instead of using
what we have (or even implementing new versions), most folks have spent
time arguing about why the Linux are not optimal, all the while we
really could be using the non-optimal ones until something better came
along.
Sigh......
Nate
--
n...@bsd.coe.montana.edu | In the middle of it ........ again.
n...@cs.montana.edu | Running/supporting one of many freely available
work #: (406) 994-4836 | Operating Systems for [34]86 machines.
home #: (406) 586-0579 | (based on Net/2, name changes all the time :-)
Newsgroups: comp.os.linux.development
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!agate!doc.ic.ac.uk!
uknet!cf-cm!cybaswan!iiitac
From: iii...@swan.pyr (Alan Cox)
Subject: Re: Status of the NET-2 port
Message-ID: <1993Sep10.113938.6835@swan.pyr>
Organization: Swansea University College
References: <1993Sep10.002132.13102@mel.dit.csiro.au>
<1993Sep10.033246.28836@super.org> <26p9pl$1rp@pdq.coe.montana.edu>
Date: Fri, 10 Sep 1993 11:39:38 GMT
Lines: 16
In article <26p9pl$...@pdq.coe.montana.edu> n...@bsd.coe.montana.edu
(Nate Williams) writes:
>In article <1993Sep10.033246.28...@super.org>,
>Donald J. Becker <bec...@super.org> wrote:
>
>Hmm, that may be the case, but I'll bet you dollars to donuts that it'll
>be awhile before the Linux networking code (not BSD Net/2 code) can
>saturate an ethernet. Not bad for *slow* code, is it?
On our hardware the Linux net code is faster than the BSD net code. The
device drivers are an order of magnitude better but the upper layers need
work. I'm actually planning on taking a hatchet to the Linux net code
and trying to produce a solid stable release with better list handlers.
Alan
iii...@pyr.swan.ac.uk
Newsgroups: comp.os.linux.development
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!europa.eng.gtefsd.com!
uunet!super!becker
From: bec...@super.org (Donald J. Becker)
Subject: Re: Status of the NET-2 port
Message-ID: <1993Sep10.140915.8057@super.org>
Sender: n...@super.org (USENET News System)
Nntp-Posting-Host: descartes
Organization: IDA Supercomputing Research Center
References: <CCoyIz.9pL@provo.novell.com>
<1993Sep10.002132.13102@mel.dit.csiro.au> <1993Sep10.033246.28836@super.org>
<26p9pl$1rp@pdq.coe.montana.edu>
Date: Fri, 10 Sep 1993 14:09:15 GMT
Lines: 62
In article <26p9pl$...@pdq.coe.montana.edu>,
Nate Williams <n...@bsd.coe.montana.edu> wrote:
>In article <1993Sep10.033246.28...@super.org>,
>Donald J. Becker <bec...@super.org> wrote:
>>BSD has historic cruft, and most of the design
>>decisions date from a far different era and are ripe to be
>>revisited.
>
>Berkeley networking code has been re-written multiple times, and
>is now considered 'the standard' upon all other networking code
>is based upon.
Yes, Berkeley is considered the standard -- almost every one else that
tried to develop a written-from-scratch protocol stack failed! They
then grabbed the BSD sources to get a product to market. BSD and
(D)ARPA did more to promote computer communications than everyone
combined. But that's not the issue here.
>>A notable example is the use of 'mbufs', a structure that
>>is at the core of BSD networking. It was designed to hold packets as
>>a linked list of protocol headers and data pages. This was a good
>>idea in the days of microcoded machines with complex addressing modes,
>>short pipelines, and very small memories. On modern machines they are
>>slower than storing always storing the packet linearly. (Would
>>someone care to comment on how many times 'mpullup()' occurs in BSD,
>>and how expensive it is?)
>
>Hmm, that may be the case, but I'll bet you dollars to donuts that it'll
>be awhile before the Linux networking code (not BSD Net/2 code) can
>saturate an ethernet. Not bad for *slow* code, is it?
How 'bout >1MB/sec using an ISA 8013 ethercard? And pretty close to
1MB/sec even using a slow 8 bit ethercard like the 3c503? The Linux
drivers add a lot of cruft to implement ping-pong transmit buffers,
but it pays off in performance. (Two notes: some boards, like the
AT1500, can do back-to-back packets in hardware making saturating the
ethernet easier. The 8013 and 3c503 must be setup anew for each
packet. Also, these performance figures were from earlier kernels,
the current upper-level code is slower. The point is that Linux
networking _could_ nearly saturate the net with even the cheapest
hardware.)
Few people dispute that mbufs are no longer a good idea, yet they are
still used in BSD, correct? Would you clarify your earlier assertion
about re-writes?
>A good example of this in Linux was the original shared libraries.
>People were able to use the (non-optimal) shared library packages
>because they needed them. Because they were non-optimal, they were
>modified (which caused the users grief, but you didn't *have* to
>upgrade). Today, they are fairly well done.
That's the way I think all Linux development should be done.
Although the libraries did occasionally cause grief, the changes were
backwards-compatible when possible.
--
Donald Becker bec...@super.org
IDA Supercomputing Research Center
17100 Science Drive, Bowie MD 20715 301-805-7482
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!europa.eng.gtefsd.com!
uunet!olivea!decwrl!decwrl!usenet.coe.montana.edu!bsd.coe.montana.edu!nate
From: n...@bsd.coe.montana.edu (Nate Williams)
Newsgroups: comp.os.linux.development
Subject: Re: Status of the NET-2 port
Date: 11 Sep 1993 18:57:05 GMT
Organization: Montana State University, Bozeman MT
Lines: 74
Message-ID: <26t721$81u@pdq.coe.montana.edu>
References: <CCoyIz.9pL@provo.novell.com> <1993Sep10.033246.28836@super.org>
<26p9pl$1rp@pdq.coe.montana.edu> <1993Sep10.140915.8057@super.org>
NNTP-Posting-Host: bsd.coe.montana.edu
Donald J. Becker <bec...@super.org> wrote:
>Nate Williams <n...@bsd.coe.montana.edu> wrote:
>>In article <1993Sep10.033246.28...@super.org>,
>>Donald J. Becker <bec...@super.org> wrote:
>>>BSD has historic cruft, and most of the design
>>>decisions date from a far different era and are ripe to be
>>>revisited.
>>
>>>A notable example is the use of 'mbufs', a structure that
>>>is at the core of BSD networking. It was designed to hold packets as
>>>a linked list of protocol headers and data pages. This was a good
>>>idea in the days of microcoded machines with complex addressing modes,
>>>short pipelines, and very small memories. On modern machines they are
>>>slower than storing always storing the packet linearly. (Would
>>>someone care to comment on how many times 'mpullup()' occurs in BSD,
>>>and how expensive it is?)
>>
...
>Few people dispute that mbufs are no longer a good idea, yet they are
>still used in BSD, correct? Would you clarify your earlier assertion
>about re-writes?
I never stated that the Net/2 code was perfect, but that it in general
is much faster than the code before, and from what I understand there
was work contributed to CSRG to remove the above problems.
My point was the below point. If things need to be re-written, and
folks are going to do the work required *even if* a working package
is other there, or can be soon, then give folks something that works,
and then worry about making it perfect.
So, we both agree that the BSD code needs to be re-written. However,
it's much faster to take what's already there and make it work, give
it to folks who need it, and then re-write and debug a better system
which will eventually replace the older/slower code.
>
>>A good example of this in Linux was the original shared libraries.
>>People were able to use the (non-optimal) shared library packages
>>because they needed them. Because they were non-optimal, they were
>>modified (which caused the users grief, but you didn't *have* to
>>upgrade). Today, they are fairly well done.
>
>That's the way I think all Linux development should be done.
>Although the libraries did occasionally cause grief, the changes were
>backwards-compatible when possible.
So in essence, you appear to agree with my last paragraph. That's
the point I was trying to make. Not the +'s and -'s of BSD networking
code, but that it *is* much more functional than the current Linux code.
(though not perfect. Here are in general what I consider the two
biggest functional differences in Linux and BSD)
BSD - Good Networking code (still has some problems), no shared
libraries. (The reason for no shared libraries is because no one has
implemented (yet) the *perfect* shared library system)
Linux - Good shared libraries (still have problems), networking code is
rather weak in it's current state. (The reason the networking code is
weak is because the BSD networking code has problems, so it is not (yet)
in Linux)
Anyone else see a parallel here?
Nate
--
n...@bsd.coe.montana.edu | In the middle of it ........ again.
n...@cs.montana.edu | Running/supporting one of many freely available
work #: (406) 994-4836 | Operating Systems for [34]86 machines.
home #: (406) 586-0579 | (based on Net/2, name changes all the time :-)
Newsgroups: comp.os.linux.development
Path: gmd.de!newsserver.jvnc.net!darwin.sura.net!ra!tantalus.nrl.navy.mil!eric
From: e...@tantalus.nrl.navy.mil (Eric Youngdale)
Subject: Re: Status of the NET-2 port
Message-ID: <CD7J2y.1Av@ra.nrl.navy.mil>
Sender: use...@ra.nrl.navy.mil
Organization: Naval Research Laboratory
References: <26p9pl$1rp@pdq.coe.montana.edu> <1993Sep10.140915.8057@super.org>
<26t721$81u@pdq.coe.montana.edu>
Date: Sat, 11 Sep 1993 20:47:22 GMT
Lines: 41
In article <26t721$...@pdq.coe.montana.edu> n...@bsd.coe.montana.edu
(Nate Williams) writes:
>(though not perfect. Here are in general what I consider the two
>biggest functional differences in Linux and BSD)
>
>BSD - Good Networking code (still has some problems), no shared
>libraries. (The reason for no shared libraries is because no one has
>implemented (yet) the *perfect* shared library system)
>
>Linux - Good shared libraries (still have problems), networking code is
>rather weak in it's current state. (The reason the networking code is
>weak is because the BSD networking code has problems, so it is not (yet)
>in Linux)
>
>Anyone else see a parallel here?
Yes, I see it. Hoisted by our own petard as it were. First of all, I
would like to say that I do appreciate the efforts of the people working on the
new network code, and I would like to see it finished and stable. However, if
the new network code has a long way to go before it is stable, it does make
quite a bit of sense to have the BSD network code available just so that people
do not have to suffer while we are waiting for the "real" network code to be
finished and debugged. Note that I have no idea how much work this would
actually entail.
Could someone on the "inside" make a real, *honest* guess as to how
long it will be before the linux network code will be stable under most
curcumstances (esp on a high traffic network, like we have at work)?
Finally, the parallels are actually stronger than you might realize.
When I did the most recent shared library implementation with dynamic linking,
I knew that in the long run there would be a very strong possibility that we
would switch to the ELF object/executable file format, which has it's own
method of dynamic linking that is considered to be quite good. Even as I was
doing it, I realized that what is now the current shared library scheme might
merely be considered a stopgap measure intended to make life easier until ELF
support in binutils and gas are stable.
-Eric
--
"When Gregor Samsa woke up one morning from unsettling dreams, he
found himself changed in his bed into a lawyer."
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!darwin.sura.net!
news-feed-2.peachnet.edu!concert!samba.oit.unc.edu!sunSITE!mdw
From: m...@sunSITE.unc.edu (Matt Welsh)
Newsgroups: comp.os.linux.development
Subject: Re: Status of the NET-2 port
Date: 11 Sep 1993 22:36:18 GMT
Organization: Linux. It's not just for breakfast anymore.
Lines: 37
Message-ID: <26tjt2$a25@samba.oit.unc.edu>
References: <CCoyIz.9pL@provo.novell.com> <26epsv$1gc@smurf.sub.org>
<1993Sep10.002132.13102@mel.dit.csiro.au>
NNTP-Posting-Host: calypso.oit.unc.edu
In article <1993Sep10.002132.13...@mel.dit.csiro.au>,
Robert Smart <sm...@squid.mel.dit.CSIRO.AU> wrote:
>be organized internally so that it could easily track networking
>developments from Berkeley it would be a big plus. For example
>you would then get:
>
> 1. Multicast.
>
> 2. CLNP (OSI connectionless protocol and one of the contenders for
> the next generation of IP).
>
> 3. All the experiments with contenders for the new IP are being done
> in a BSD context.
>
> 4. Low level support for lots of networking devices: ethernet, token
> ring, FDDI, ISDN, ATM/BISDN, etc...
>
> 5. Network debugging tools.
>
>We don't want to have to duplicate all this work.
"We"?
If this was the attitude Linus took when he developed the kernel, would
we be where we are today?
>It would be really nice if the people who've worked on
>Linux Net-2 would say to Linus "We've learnt a lot and won't be
>upset if you change again".
It has nothing to do with this. The NetBSD stuff is not covered by the GPL.
Non-GPL'd code CAN NOT go into the Linux code. It would not only go against
the GPL but cause a lot of other problems as well.
mdw
--
Send submissions for comp.os.linux.announce to: linux-annou...@tc.cornell.edu
Path: gmd.de!Germany.EU.net!mcsun!uknet!doc.ic.ac.uk!agate!
howland.reston.ans.net!darwin.sura.net!news-feed-2.peachnet.edu!concert!
samba.oit.unc.edu!sunSITE!mdw
From: m...@sunSITE.unc.edu (Matt Welsh)
Newsgroups: comp.os.linux.development
Subject: Re: Status of the NET-2 port
Date: 11 Sep 1993 23:00:29 GMT
Organization: Linux. It's not just for breakfast anymore.
Lines: 20
Message-ID: <26tlad$asg@samba.oit.unc.edu>
References: <26p9pl$1rp@pdq.coe.montana.edu> <1993Sep10.140915.8057@super.org>
<26t721$81u@pdq.coe.montana.edu> <CD7J2y.1Av@ra.nrl.navy.mil>
NNTP-Posting-Host: calypso.oit.unc.edu
In article <CD7J2y....@ra.nrl.navy.mil>,
Eric Youngdale <e...@tantalus.nrl.navy.mil> wrote:
> Yes, I see it. Hoisted by our own petard as it were. First of all, I
>would like to say that I do appreciate the efforts of the people working on the
>new network code, and I would like to see it finished and stable. However, if
>the new network code has a long way to go before it is stable, it does make
>quite a bit of sense to have the BSD network code available just so that people
>do not have to suffer while we are waiting for the "real" network code to be
>finished and debugged. Note that I have no idea how much work this would
>actually entail.
The problem that everyone seems to be forgetting is that this would violate
the GPL and not allow Linux to be distributed as per the GPL, as it is now.
It has very little to do with whether or not the BSD code is better than
the Linux code, or whether or not BSD is in a lawsuit with USL.
mdw
--
Send submissions for comp.os.linux.announce to: linux-annou...@tc.cornell.edu
Newsgroups: comp.os.linux.development
Path: gmd.de!newsserver.jvnc.net!udel!wupost!cs.utexas.edu!uunet!pipex!
sunic!uts!iesd!news.iesd.auc.dk!abraham
From: abra...@iesd.auc.dk (Per Abrahamsen)
Subject: Re: Status of the NET-2 port
In-Reply-To: mdw@sunSITE.unc.edu's message of 11 Sep 1993 22:36:18 GMT
Content-Type: text/plain; charset=iso-8859-1
Message-ID: <ABRAHAM.93Sep12060945@steinhaus.iesd.auc.dk>
Sender: n...@iesd.auc.dk (UseNet News)
Content-Transfer-Encoding: 8bit
Organization: AUC
X-Newsreader: GNUS 3.15
References: <CCoyIz.9pL@provo.novell.com> <26epsv$1gc@smurf.sub.org>
<1993Sep10.002132.13102@mel.dit.csiro.au>
<26tjt2$a25@samba.oit.unc.edu>
Mime-Version: 1.0
Date: 12 Sep 1993 04:09:45 GMT
Lines: 17
>>>>> "Matt" == Matt Welsh <m...@sunSITE.unc.edu> writes:
Matt> It has nothing to do with this. The NetBSD stuff is not covered
Matt> by the GPL. Non-GPL'd code CAN NOT go into the Linux code. It
Matt> would not only go against the GPL but cause a lot of other
Matt> problems as well.
This happens to be wrong. The BSD copyright is liberal enough to be
used in any project under any conditions, as long as UC is given
proper credit.
If you don't understand the legal language of the BSD copyright and
the GPL, consider the fact that GNU indent, distributed by the FSF,
is covered by both the BSD copyright and the GPL.
I have no idea of what `other problems' you are talking about.
Newsgroups: comp.os.linux.development
Path: gmd.de!Germany.EU.net!mcsun!uunet!haven.umd.edu!darwin.sura.net!ra!
tantalus.nrl.navy.mil!eric
From: e...@tantalus.nrl.navy.mil (Eric Youngdale)
Subject: Re: Status of the NET-2 port
Message-ID: <CD8q1G.37x@ra.nrl.navy.mil>
Sender: use...@ra.nrl.navy.mil
Organization: Naval Research Laboratory
References: <26t721$81u@pdq.coe.montana.edu> <CD7J2y.1Av@ra.nrl.navy.mil>
<26tlad$asg@samba.oit.unc.edu>
Date: Sun, 12 Sep 1993 12:15:15 GMT
Lines: 35
In article <26tlad$...@samba.oit.unc.edu> m...@sunSITE.unc.edu (Matt Welsh)
writes:
>In article <CD7J2y....@ra.nrl.navy.mil>,
>Eric Youngdale <e...@tantalus.nrl.navy.mil> wrote:
>> Yes, I see it. Hoisted by our own petard as it were. First of all, I
>>would like to say that I do appreciate the efforts of the people working on the
>>new network code, and I would like to see it finished and stable. However, if
>>the new network code has a long way to go before it is stable, it does make
>>quite a bit of sense to have the BSD network code available just so that people
>>do not have to suffer while we are waiting for the "real" network code to be
>>finished and debugged. Note that I have no idea how much work this would
>>actually entail.
>
>The problem that everyone seems to be forgetting is that this would violate
>the GPL and not allow Linux to be distributed as per the GPL, as it is now.
>
>It has very little to do with whether or not the BSD code is better than
>the Linux code, or whether or not BSD is in a lawsuit with USL.
Then I suggest you look at the file /usr/src/linux/net/inet/slhc.c.
This file has a Berkeley copyright on it. I would have never know about this
if Don Becker had not pointed it out to me. Apparently this was done without
discussion of any kind on any of the lists, although I think Linus is at least
aware of it.
I am sure that if we wanted to, we could figure out a way to deal with
the legal niceties and still get the BSD network code in the kernel as an
interim measure. Note that I still feel that in the long run having our own
GPL version would be better, but having BSD code available would take the head
off as it were.
-Eric
--
"When Gregor Samsa woke up one morning from unsettling dreams, he
found himself changed in his bed into a lawyer."
Path: gmd.de!Germany.EU.net!mcsun!uknet!doc.ic.ac.uk!agate!
howland.reston.ans.net!darwin.sura.net!news-feed-2.peachnet.edu!concert!
samba.oit.unc.edu!sunSITE!mdw
From: m...@sunSITE.unc.edu (Matt Welsh)
Newsgroups: comp.os.linux.development
Subject: Re: Status of the NET-2 port
Date: 12 Sep 1993 17:21:29 GMT
Organization: Linux. It's not just for breakfast anymore.
Lines: 28
Message-ID: <26vlqp$f80@samba.oit.unc.edu>
References: <CCoyIz.9pL@provo.novell.com>
<1993Sep10.002132.13102@mel.dit.csiro.au> <26tjt2$a25@samba.oit.unc.edu>
<ABRAHAM.93Sep12060945@steinhaus.iesd.auc.dk>
NNTP-Posting-Host: calypso.oit.unc.edu
In article <ABRAHAM.93Sep12060...@steinhaus.iesd.auc.dk>,
Per Abrahamsen <abra...@iesd.auc.dk> wrote:
>> "Matt" == Matt Welsh <m...@sunSITE.unc.edu> writes:
>> It has nothing to do with this. The NetBSD stuff is not covered
>> by the GPL. Non-GPL'd code CAN NOT go into the Linux code. It
>> would not only go against the GPL but cause a lot of other
>> problems as well.
>
>This happens to be wrong. The BSD copyright is liberal enough to be
>used in any project under any conditions, as long as UC is given
>proper credit.
An idiot am I. Thanks to those who pointed out my misconception; somewhere
along the way I had been given the impression that BSD code would be
incompatible with the GPL; thus, it could not be included in the standard
kernel.
I should have known better than to try to speak legalese...
As for the SLIP header compression code: in some ways, I would not like to
see BSD code unnecessarily end up in the Linux kernel. If there are
alternatives, developers should use them. Don Becker has rightfully
suggested that the slhc.c code should be duplicated from the specifications
instead of copied verbatim. I agree.
mdw
--
Send submissions for comp.os.linux.announce to: linux-annou...@tc.cornell.edu
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!darwin.sura.net!
news-feed-2.peachnet.edu!concert!samba.oit.unc.edu!sunSITE!mdw
From: m...@sunSITE.unc.edu (Matt Welsh)
Newsgroups: comp.os.linux.development
Subject: Re: Status of the NET-2 port
Date: 12 Sep 1993 23:02:25 GMT
Organization: Linux. It's not just for breakfast anymore.
Lines: 30
Message-ID: <2709q1$q3h@samba.oit.unc.edu>
References: <26t721$81u@pdq.coe.montana.edu> <CD7J2y.1Av@ra.nrl.navy.mil>
<26tlad$asg@samba.oit.unc.edu> <CD8q1G.37x@ra.nrl.navy.mil>
NNTP-Posting-Host: calypso.oit.unc.edu
In article <CD8q1G....@ra.nrl.navy.mil>,
Eric Youngdale <e...@tantalus.nrl.navy.mil> wrote:
>In article <26tlad$...@samba.oit.unc.edu> m...@sunSITE.unc.edu (Matt Welsh)
writes:
>>The problem that everyone seems to be forgetting is that this would violate
>>the GPL and not allow Linux to be distributed as per the GPL, as it is now.
>
> Then I suggest you look at the file /usr/src/linux/net/inet/slhc.c.
>This file has a Berkeley copyright on it.
I have looked at all of the NET-2e rev ALPHA-4 code and this file does not
exist. None of the files in this code appear to have a BSD copyright. Are
we referring to different versions of the code?
I don't have stock pl12 handy; someone may want to compare slhc.c and
the (apparent analogue) net/drv/slip/compress.c.
> I am sure that if we wanted to, we could figure out a way to deal with
>the legal niceties and still get the BSD network code in the kernel as an
>interim measure. Note that I still feel that in the long run having our own
>GPL version would be better, but having BSD code available would take the head
>off as it were.
Perhaps. I am not opposed to working with BSD code, but the entire idea
of Linux is to roll your own kernel. Linus could have opted to merge in
BSD kernel code long ago; he didn't, and I think for that reason we are
able to understand the code in its entirety.
mdw
--
Send submissions for comp.os.linux.announce to: linux-annou...@tc.cornell.edu
Newsgroups: comp.os.linux.development
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!
math.ohio-state.edu!cs.utexas.edu!uunet!pipex!uknet!cf-cm!cybaswan!iiitac
From: iii...@swan.pyr (Alan Cox)
Subject: Re: Status of the NET-2 port
Message-ID: <1993Sep13.123550.7030@swan.pyr>
Organization: Swansea University College
References: <1993Sep10.033246.28836@super.org> <26p9pl$1rp@pdq.coe.montana.edu>
<1993Sep10.140915.8057@super.org>
Date: Mon, 13 Sep 1993 12:35:50 GMT
Lines: 31
In article <1993Sep10.140915.8...@super.org> bec...@super.org
(Donald J. Becker) writes:
>Yes, Berkeley is considered the standard -- almost every one else that
>tried to develop a written-from-scratch protocol stack failed! They
>then grabbed the BSD sources to get a product to market. BSD and
>(D)ARPA did more to promote computer communications than everyone
>combined. But that's not the issue here.
There are a considerable number of non berkeley TCP/IP stacks around. I do
find it hard to take BSD is perfect attitudes seriously at times, they got
the broadcast address wrong and most BSD machines still dont do URG tcp right.
I personally use KA9Q as a reference model. THe current KA9Q NOS code is the
most clear solid TCP/IP stack I've ever met - its also a bit slow alas.
>
>>A good example of this in Linux was the original shared libraries.
>>People were able to use the (non-optimal) shared library packages
>>because they needed them. Because they were non-optimal, they were
>>modified (which caused the users grief, but you didn't *have* to
>>upgrade). Today, they are fairly well done.
>
>That's the way I think all Linux development should be done.
>Although the libraries did occasionally cause grief, the changes were
>backwards-compatible when possible.
Indeed and I'm still using programs linked for the very earliest shared
library revision 4 code. Some of these programs have ceased to be buggy
as the library changed none have gone wrong.
And this is the way I'm trying to build up a working 'as we have it now'
TCP/IP release (and looking for volunteers to merge in bits of FvK's still
testing bits (and checkt them properly)- especially fragmentation and tcp
options.
Alan
iii...@pyr.swan.ac.uk
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!
sol.ctr.columbia.edu!news.kei.com!bloom-beacon.mit.edu!
senator-bedfellow.mit.edu!senator-bedfellow.mit.edu!not-for-mail
From: ty...@athena.mit.edu (Theodore Ts'o)
Newsgroups: comp.os.linux.development
Subject: Re: Status of the NET-2 port
Date: 13 Sep 1993 21:23:37 -0400
Organization: The Internet
Lines: 23
Sender: dae...@athena.mit.edu
Distribution: world
Message-ID: <2736ep$ecf@senator-bedfellow.MIT.EDU>
Reply-To: ty...@athena.mit.edu (Theodore Ts'o)
NNTP-Posting-Host: senator-bedfellow.mit.edu
From: m...@sunSITE.unc.edu (Matt Welsh)
Date: 11 Sep 1993 22:36:18 GMT
It has nothing to do with this. The NetBSD stuff is not covered by the GPL.
Non-GPL'd code CAN NOT go into the Linux code. It would not only go against
the GPL but cause a lot of other problems as well.
What are you talking about? There's no problem with BSD copyrighted
code going into GPL programs --- it's the reverse that causes problems.
There is BSD copyrighted code in the GPL'ed iostreams package, which is
part of the Linux libc. Every single time you hear your console bell
ring while you're running Linux, you're using BSD-derived code. (John
Kohl added beeping to the Linux console driver around 0.10 or 0.11, and
he did so by stealing a subroutine out of BSD386.)
On the other hand, the BSD folks would not be able to take Linux code
and put it into a Non-GPL'ed work unless the get specific permission
from the author, since that would violate the GPL. This is why Linux
had to give special permission for the BSD386 folks to use the floating
point emulator from Linux.
- Ted
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!gatech!concert!
samba.oit.unc.edu!sunSITE!mdw
From: m...@sunSITE.unc.edu (Matt Welsh)
Newsgroups: comp.os.linux.development
Subject: Re: Status of the NET-2 port
Date: 14 Sep 1993 01:33:50 GMT
Organization: Linux. It's not just for breakfast anymore.
Lines: 34
Message-ID: <27371u$go5@samba.oit.unc.edu>
References: <2736ep$ecf@senator-bedfellow.mit.edu>
NNTP-Posting-Host: calypso.oit.unc.edu
In article <2736ep$...@senator-bedfellow.mit.edu>,
Theodore Ts'o <ty...@athena.mit.edu> wrote:
> From: m...@sunSITE.unc.edu (Matt Welsh)
> Date: 11 Sep 1993 22:36:18 GMT
>
> It has nothing to do with this. The NetBSD stuff is not covered by the GPL.
> Non-GPL'd code CAN NOT go into the Linux code. It would not only go against
> the GPL but cause a lot of other problems as well.
>
>What are you talking about? There's no problem with BSD copyrighted
>code going into GPL programs --- it's the reverse that causes problems.
Sigh. I really should cancel that article... it's making me look like an
idiot over and over again. :)
>There is BSD copyrighted code in the GPL'ed iostreams package, which is
>part of the Linux libc. Every single time you hear your console bell
>ring while you're running Linux, you're using BSD-derived code. (John
>Kohl added beeping to the Linux console driver around 0.10 or 0.11, and
>he did so by stealing a subroutine out of BSD386.)
Yes. I am aware now that there is very little problem (legally) with
including BSD code in a GPL application as long as proper credit is
given (it is not given, by the way, in kernels previous to 0.99.pl13a.
Thanks to Don Becker, it is now.)
Somehow I was given the impression that BSD code could not and would not
ever be included in the Linux kernel, because that would restrict distribution
of the code via the GPL. Perhaps I should stop believing everything people
tell me...
mdw, who *loves* legal-speak
--
Send submissions for comp.os.linux.announce to: linux-annou...@tc.cornell.edu