Vote in favor of keeping ATM (was: NATM still scheduled for removal - please follow up to keep it in-tree)

[Martin Birgmeier]

Hi,

I would like to vote in favor of keeping NATM in the kernel. The reason 
is that I am currently working on writing a device driver for the 
SpeedTouch USB modem, to replace ports/net/pppoa which is not supported 
on FreeBSD8+ any more. The SpeedTouch USB in fact terminates as an ATM 
connection, on top of which PPPoA needs to be layered.

 From my experiments with compiling a kernel with "device atm" and 
"options NATM", I know that currently only the former works, this being 
due to unmaintained and broken code dealing with routing entries.

I am currently not much of a kernel code expert, but have already 
managed to write enough of the USB side of the device driver to load the 
modem's firmware. The next step would be to connect it to the ATM stack, 
using this route:

     1. Terminate as ATM interface (ATM cells arriving);
     2. The ATM stack implements AAL5 (I hope);
     3. Capture the interface via ng_atm (which, as far as I understand, 
would more aptly be named ng_natm);
     4. Extend the functionality of ng_atmllc (which basically does a 
small subset of RFC2684) to also do LLC/ISO (cf. RFC2364) (then better 
named ng_llc);
     5. Couple the resultant PPP stream to ng_ppp;
     6. Use something to configure the VPI/VCI (what?);
     7. Run ports/net/mpd5 on that netgraph node.

5. and 7. could be replaced by ng_tty and ppp(8), but that would be the 
poorer choice as all traffic would have to go through userland again as 
it is doing with ports/net/pppoa.

For this I'd need a) a working ATM stack and b) the help of some kind 
souls in hooking everything up. Hans-Petter Selasky has already been 
very helpful with the USB part in private mail, and I actually wanted to 
solicit more help on the networking side of things privately in order 
not to trumpet out something which I'll probably finish only after 
considerable time, but reading the removal message I felt that I needed 
to make my needs public.

Regards,

Martin

p.s. A few :-) of the questions I have are

- why the original (as I understand HARP) ATM stack was removed (in the 
CVS logs the reason cited is the usual giant lock issue of that time),

- what the differences between the atm and natm stacks are (as I 
understand the latter only supports a subset of the functionality of the 
former - only AAL5?),

- why AF_NATM is different from AF_ATM (hinting that NATM is not a 
replacement of ATM),

- whether and how it is even possible to inject raw ATM cells,

- whether I even need "options NATM" (currently I can happily 
instantiate a (of course non-functional) ATM interface using just 
"device atm"),

- what do I need to do on the USB side to start receive and transmit 
machines (do I need to start separate kernel threads or just issue two 
usbd_transfer_setup() calls as for loading the firmware),

- etc. etc.

I do of course read the source, but with the scarce documentation 
available that's a steep learning curve.

-- 
Martin Birgmeier
Vienna
Austria