[2.4] ATM SAR support, based on SARlib

diff --exclude-from=/home/ldb/src/linux-exclude -u -r -N linux-base/Documentation/networking/atmsar.txt linux/Documentation/networking/atmsar.txt
@@ -0,0 +1,104 @@
+#
+## ATM SAR Library  (C) 2000, Johan Verrept ([email protected])
+#
+# 30/may/2002, Luca Barbieri <[email protected]>:
+#     "sarlib"/"SARlib" name replaced with "atmsar"/"ATM SAR"
+
+For updates, check the linux-atm mailing list or mail me.
+The updates will be very infrequent because I don't have much time.
+Any remarks, patches and bug fixes are welcome.
+
+WARNING: This is experimental software. Use at your own risk.
+
+License
+=======
+
+This code falls under the GNU Public License, see COPYING
+If you want to use this in a commercial product, contact me.
+
+Usage & requirements
+====================
+
+Usage: Just link this library to your driver/module/kernel.
+Requirements:
+	This needs the Linux ATM stuff, but can be easily ported to
+	any platform.
+
+API
+===
+
+The API to the ATM SAR is simple. At least, I tried to make it as simple as I
+could.  I alsi tried to map it to the ATM Linux API as much as I could.
+
+There is a atmsar_open() function which will initialize the atmsar_vcc
+structure with the provided parameters. The atmsar_close() function frees
+this all.
+the atmsar_open() function is passed in a type, all the header parts, a
+pointer to the Linux ATM vcc, a pointer to a list of atmsar_vcc's and a
+flags field.
+there are 2 flags available now:
+	ATMSAR_USE_53BYTE_CELL  will force atmsar_encode_rawcell() to produce
+53 byte cell in stead of the linux 52 byte cells.
+	ATMSAR_SET_PTI          this will cause the pti bit of the last cell
+int the provided buffer to be set ( by atmsar_encode_rawcell())
+
+Real SARing happens in the atmsar_encode_xxx() and atmsar_decode_xxx()
+functions. Everything is straight forward for the encoding of the data,
+althought there are a few assumptions.
+
+atmsar_encode_rawcell assumes it gets a multiple of 48 bytes.
+	if ATMSAR_SET_PTI is set, it assumes a full aal5 pdu is supplied.
+	It does NOT calculate the cell header CRC at the moment.
+
+atmsar_encode_aal5    assumes it gets a full aal5 pdu.
+
+The decode functions have no assumptions. Both decode functions need to be 
+repeated until they return NULL.  
+
+atmsar_decode_rawcell() requires a LIST of atmsar_vcc's. This allows the user 
+to pass in any cells they received, atmsar_decode_rawcell() will drop the 
+ones it doesn't know, the others are copied into the relevant atmsar_vcc 
+reassembly buffer.  Depending on the type of reassemly (only AAL5 at the
+moment) it will return a pointer to that buffer when a complete AAL5 pdu 
+has been received. The third argument will contains a pointer the relevant 
+atmsar_vcc.  You must repeat the call with the same arguments after
+processing the buffer, to allow atmsar_decode_rawcell() to process the
+remaining cells in the receive skb. It does NOT check the cell header crc.
+
+atmsar_decode_aal5() requires a complete AAL5 packet to process.
+This will do aal5 length and crc checking.  There is some intelligence in
+there that will try to recover from an illegal length.  It will take the
+length from the trailer and check whether the crc over this part is valid.
+This allows the ATM SAR to only drop 1 AAL5 pdu when the last cell of a pdu
+is lost. ( otherwise it would have to drop both...)
+
+There is also a atmsar_alloc_tx function now.  It is supposed to be called
+with a atmsar_vcc structure instead of a atm_vcc, I had to do this because I
+had no way of getting to the atmsar_vcc structure from the atm_vcc
+structure... the user program will have to wrap the atmsar_vcc function.
+BE CAREFULL!!  the atmsar_open function will copy the alloc_tx pointer from
+the atm_vcc and call it!  You cannot set the alloc_tx function in the vcc 
+BEFORE passing it to atmsar_open!! You will have to do it afterwards...
+
+To Do
+=====
+
+Lots to do.
+
+- Adding AAL1, AAL34 and maybe even AAL2 ( probably not, unless the
+	telephony thing wants it, need to look into it).
+- Add atm cell header crc calculation.
+- more optimalisations
+	- crc_calc / copy combinations.
+- completing support to run as well in userspace as in kernel space.
+	( replacing skb's with generalised functions, define for kernel
+	space to skb functions and to ATM SAR buffer system for user space.
+- completing buffer management on receive size.  introduced mru setting to
+	reduce problem. would maybe be better to go to scatter gather method.
+
+Acknowledgements
+================
+
+Thanks to :
+
+- Whoever wrote the CRC routines in linux/drivers/net/wan/sbni.c

diff --exclude-from=/home/ldb/src/linux-exclude -u -r -N linux-base/net/atm/Makefile linux/net/atm/Makefile
@@ -9,12 +9,12 @@
 
 O_TARGET	:= atm.o
 
-export-objs 	:= common.o atm_misc.o raw.o resources.o ipcommon.o proc.o
+export-objs 	:= common.o atm_misc.o raw.o resources.o ipcommon.o proc.o atmsar.o
 
 list-multi	:= mpoa.o
 mpoa-objs	:= mpc.o mpoa_caches.o mpoa_proc.o
 
-obj-$(CONFIG_ATM) := addr.o pvc.o signaling.o svc.o common.o atm_misc.o raw.o resources.o
+obj-$(CONFIG_ATM) := addr.o pvc.o signaling.o svc.o common.o atm_misc.o raw.o resources.o atmsar.o
 
 ifeq ($(CONFIG_ATM_CLIP),y)
 obj-y += clip.o