Re: [Linux-ATM-General] Better instrumenting ATM/DSL

[chas w. - C. <ch...@cm...>]

On Tue, 07 Dec 2010 12:45:53 -0800
Philip Prindeville <phi...@re...> wrote:

> Yeah, I brought up using netdev's a month or so ago, but it wasn't
> warmly received.

you wanted to put atm pdu's into the network stack (so you can watch
them with tcpdump) -- atleast i think you asked about that.  you cant
push 'packets' to be examined by tcpdump without having a netdev
interface (atleast i dont think you can).

> I have no problem with it appearing in the output of 'ifconfig'.

i bothers me a little bit.  people are going to try to ifconfig
interfaces on it and then wonder why it doesnt work.  i would just
prefer that the parent interfaces stay invisible.

> People use Ethernet interfaces in a purely VLAN environment, without
> being confused by the presence of the 'naked' Ethernet interface, so
> I think it's a red herring.

maybe.  i still think we can implement netlink without netdevs.  like i
said i am of two minds about the problem.

> It was suggested that using netdev's would also effect the data path,
> though I have to say I don't understand why this would be so.

netdevs dont have to affect the data path.  only if we decide to push
the atm pdus through the network queues.  as of now, when an ethernet
card finishes receiving a packet, it pushes the packet onto a queue to
be processed by someone/something else that was subscribed to the queue.
this has a couple of side effects -- a small delay but decoupling
between the parts of the network stack which makes it easier to write
things. the atm stack pushes pdus directly to the protocol (aal5
sockets, lec, clip). this means the protocol handlers must be interrupt
safe and capable of running in any context that the atm drivers choose
to deliver pdus.