Re: Vote in favor of keeping ATM (was: NATM still scheduled for removal - please follow up to keep it in-tree)
Hi Martin, On Sat, 19 Feb 2011, Martin Birgmeier wrote: MBp.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 MBlogs 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 MBthe latter only supports a subset of the functionality of the former - only MBAAL5?), 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 MBreplacement 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 MBusbd_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? MBI do of course read the source, but with the scarce documentation available MBthat'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 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Vote in favor of keeping ATM (was: NATM still scheduled for removal - please follow up to keep it in-tree)
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 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: Vote in favor of keeping ATM (was: NATM still scheduled for removal - please follow up to keep it in-tree)
On Saturday 19 February 2011 15:14:17 Martin Birgmeier wrote: - 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), USB already has some kernel threads which all callbacks are executed from. If your software does not sleep I.E. pause() in the callbacks, then it should be OK to execute the ATM stack directly from USB. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
