R: [ATMSAR] Request for review - update #1

["Giampaolo Tomassoni" <g.tomassoni@libero.it>]

> -----Messaggio originale-----
> Da: Alistair John Strachan [mailto:s0348365@sms.ed.ac.uk]
> Inviato: domenica 4 settembre 2005 18.21
> 
> ...omissis...
> 
> Just out of curiosity, is there ANY reason why this has to be done in the 
> kernel? The PPPoATM module for pppd implements (via linux-atm) a 
> completely 
> userspace ATM decoder.. if anything, now redundant ATM stack code 
> should be 
> REMOVED from Linux!

This may be true for AAL5 support, which is the way by which data is actually transferred between ADSL DSLAMs and CPE equipment.

This may not be generally true, however: most providers are already delivering internet+voice solutions over ADSL channels (here in Italy, in example, Telecom offers Alice Mia, which is an ADSL line with internet access and VoIP for added voice capabilities). Albeit the voice part of these solutions are actually based on VoIP technology, it is not the best way to do this. In the future, I believe we will easily see internet + voice sols based over AAL5 + AAL2/3, or even multi voice channels over AAL2/3 over ADSL (replacing ISDN PRIs and multi-BRIs -based lines for PABX connection).

When (and if) that will happen, we will probabily need a kernel-based solution since cell timing and QoS is a much stricter requirement with non-AAL5 encodings, such that it is easier to attain from inside the kernel than from userland.

So, I'm not that shure all the ATM code is to be stripped out of the kernel. Maybe it can be done with the PPPoATM network interface. But probably it can't be done with the ATM core and the ATM SAR code. Wherever the latter will be in ATMUSB, in ATMSAR or in a device driver.

The PPPoATM module is a network interface. It stays on the other side of the ATM world: [netif] <-> [PPPoATM] <-> [atmif] <-> [ATM] <-> [ATMSAR] <-> [device driver]. I'm not a PPPoATM expert, but it may probably be possible to have all the PPPoATM code in userland. But the [ATM] <-> [ATMSAR] <-> [device driver] chain is probably too close to hardware to gain any benefit by "userlanding" it.


> 
> ...omissis...
> 
> 
> -- 
> Cheers,
> Alistair.

Cheers,

	giampaolo

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/