* Removed some superfluous documents.

* Moved the documentation that might still be helpful into an "obsolete" directory.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18237 a95241bf-73f2-0310-859d-f6bbb57e9c96

docs/develop/net/00-Design_general

@@ -1,97 +0,0 @@
-Just some general thoughts that have occurred to me as I've started
-looking at stuff related to designing a network stack...
-
-These are in no particular order.
-
-General Jottings
-----------------
-
-- zero-copy is a laudible aim, but in reality single copy is probably
-  as good as we're going to get to.  Basically this means that we copy data
-  into the stack at some point.
-- we should use a version of the mbuff's that the BSD stack uses with changes
-  so we use them more efficiently for our stack.
-- probably need an rx and tx queue for frames.
-- we should reallt be dealing with frames as soon as we can in the stack,
-  though we don't want to fragment earlier than we need to - what a quandry!
-- it should be possible to stack/reorder modules as needed. This would be cool
-  if we could deal with input from other sources, e.g. data from a USB port
-  to be fed into a ppp stack, onto an atm/ethernet frame module and upwards.
-
-
-Userland vs Kernel Land
------------------------
-
-This has been decided as follows...
-- initial stack will be userland
-- stack should be modular enough that it could be moved into kernel with
-  little or no real work.
-
-
-Initial Protocols
------------------
-
-- ethernet/802.x encapsulation (rx only for 802.x)
-- slip (?)
-- ppp (?)
-- arp
-- ipv4
-- icmp (v4)
-- udp
-- tcp
-
-Extra's
--------
-
-- appletalk ?
-- ipv6
-- icmpv6
-- ipv6 discovery (arp for v6)
-- atm encapsulation module?
-- usb interface (net stack to usb??)
-
-Stack Map
-=========
-
-So, how does this all fit together???
-
-[david: My ascii art is terrible, so hope this works out :)]
-
-			=================
-			= User apps	=   		USERLAND
-			=================
-			|	|	|
-			|	|	|
-		=========   =========	=========
-		= UDP   =   = ICMP* =	= TCP	=	
-		=========   =========	=========
-			 \      |      /
-			  \     |     /
-                         ===============
-     MBUF	         =  IP (v4/v6) =
-                         ===============
-                                |     
-                -----------------------------
-                                |           |
-                         ===============    |   =======
-     BUFFER              = Eth/802.x   =----|---= ARP =
-                         ===============    |   =======
-                                |           |
-                ----------------------------|----- 
-				|           |
-			   ===========      |
-			   = NIC IF  =      |           KERNEL
-			   ===========
-
-* ICMP is used as a placeholder for both ICMPv4 and ICMPv6, which are very
-  different from each other in scope and usage.
-
-Basically every module only needs to be able to call the module that deal with the
-input/output of the protocol it find encapsulated, i.e. if IP finds a TCP packet
-it simply needs to be able to call tcp_input and pass the mbuf along. There is a
-requirement that each call to xxx_input gives the length of the header as they're 
-variable in most protocols.
-
-This just starts to scratch the surface, but I hope gives more of an idea
-of what's been bouncing around in my head. :)
-

docs/develop/net/10-NetworkDrivers

@@ -1,13 +0,0 @@
-Network Drivers - Milestone #1
-
-Having done some work on the Tulip cards, here are some general
-comments.
-
-- we should have both an rx and tx queue and pop/push from the queue
-  in the system rx/tx_thread.  this should provide good performance
-- order of calling is
-	: detect
-	: init
-- the driver is normally in 2 pieces, one for the general calls and
-  one for the device specific stuff.
-

docs/develop/net/30-NetCache

@@ -1,22 +0,0 @@
-Net Cache - Milestone #2
-========================
-
-Hmm, a general purpose net cache.
-
-Types of Cache
-==============
-
-What are we likely to need a fast cache for?  Look below.
-
-- ipv4 address to ethernet MAC address (ARP)
-- MAC address to IPv4 (RARP)
-- list of IPv6 neighbours/routers/prefix's
-
-There remain problems in that for many of these needs additional
-information is required, this information being specific to the
-use at the time.
-
-However, all these uses require an ability to quickly find information
-given a key that is a number of variable length, hence the conceptual
-idea of using a hash lookup.
-

docs/develop/net/Milestones

@@ -1,66 +0,0 @@
-Milestones
-==========
-
-These were agreed 17th january 2002 in an IRC meeting.
-
-IRC log http://www.darkest.org/openbeos/netkit/02.01.17.openbeosnetkit.log
-
-Milestone	Description
-
-1		network drivers
-		It was recognised that until the team members had
-		working NIC's there was little point in trying to
-		develop a network stack.
-
-		STATUS: rtl8139 in repository
-			tulip driver written covering Netgear FA310TX
-			Ne2000 driver started
-
-2		Encapsulation
-		Ethernet packets come in 2 basic forms, 
-			ethernet encapsulation (rfc 894)
-			IEEE 802.2/3/4/5 (rfc1042)
-		We need to be able to handle both. However, we only 
-		MUST be able to send ethernet compatible frames. In pactice
-		we should try to send the frame in the same format that it
-		was received. In fact we may want to store the format used by
-		hosts?
-
-		David says this isn't easy to do with the current newos
-		stack design.
-
-		STATUS: newos has ethernet support, but with the current
-			architecture it's difficult to add fully transparent
-			support for other encapsulations.
-
-3		ARP module
-		Once we can get frames from the network, one of the first
-		things we need to do is start capturing and caching ARP
-		requests.
-		NB david thinks this should be aimed at providing more
-		general purpose caching so it's useful beyond ARP. he
-		suggests we call this a Net Cache module.
-
-		STATUS: newos has an arp module, though cache needs work
-			and is limited to ipv4
-
-4		IPv4 checksums + routing
-		Implement IPv4 checksums and routing
-
-		STATUS: newos has a basic version of thisi
-
-5		IPv4 ICMP
-		Add ICMP support to out IPv4 module
-
-6		IPv4 Fragmentation
-		This will be interesting, adding support for reconstructing
-		and deconstructing packets into suitable frames for transport.
-		NB this needs to be abel to deal with different sizes of 
-		frame.
-
-		STATUS:
-
-7		TCP/UDP
-		
-		STATUS: newos has rudimentary UDP support
-

docs/develop/net/naming

@@ -1,20 +0,0 @@
-Document naming.
-
-Well, I've been thinking about this and I've decided that maybe 
-this formatting of the numbers we use will work. Maybe it won't, 
-but until someone else shouts...
-
-First digit is the milestone referred to, with 0 being for
-general design.
-
-Second digit:
-	- layer involved for general design
-	- incremental for milestones
-	- 0 for general design comments
-
-So, 	00 = general design principals
-	01 = general design for layer 1
-	10 = general design comments for milestone 1
-	11 = first document about milestone 1
-
-Does that work for people?