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

[Harti Brandt]

Hi Martin,

On Sat, 19 Feb 2011, Martin Birgmeier wrote:

MB>p.s. A few :-) of the questions I have are
MB>
MB>- why the original (as I understand HARP) ATM stack was removed (in the CVS
MB>logs the reason cited is the usual giant lock issue of that time),

This is one reason. Another problem was, that HARP was a rather 
umaintainable monolithic block of code. Many years ago I needed to do 
modifications in the ATM signaling and that was just impossible. So I 
decided to build all the stuff on NATM which rather nicely fits into the 
socket framework.

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

NATM is a very thin layer to be able to use VCIs directly in an 
application. All the stuff in ng_atm can be used together with NATM and 
provides a modular framework for doing ATM work. There are missing pieces 
like CLIP and a decent connection of the ATM signaling to the socket 
interface, but my interest in this dropped because ATM is basically given 
up by industry. Except for the use in ADSL (which is slowly phased out by 
the new DSL standards) it is dead.

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

AF_NATM allows you to bind VCIs with AAL5 or AAL0 (raw cells). AF_ATM had 
also an ad-hoc interface to signaling.

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

AF_NATM with AAL0.

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

Since time has passed I'm not sure on this. You need optiosn NATM either 
to do IP over ATM directly or to get the AF_NATM stuff. Don't remember, 
sorry.

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

I'v no idea on this.

I would suppose, that your driver would appear to the atm stack as an ATM 
interface, right?

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

You may try to look up the original paper on NATM - its a nice reading as 
far as I remember...

harti