Using net_devices with ATM/DSL

Using net_devices with ATM/DSL

[Philip Prindeville]

I was trying to get this discussion rolling on linux-atm-general but didn't have much luck.

I was wondering what the downside to having ATM/DSL interfaces use net_devices would be?

Part of the reason for wanting to do this is to have an end-point to send/receive netlink messages to, so that the interface can report carrier state transitions, bit rates, bit-error rates, SNR, attenuation, constellations, transmitter gain, etc.

Seems simple enough.

Why not do this?

Thanks,

-Philip

Re: Using net_devices with ATM/DSL

[Florian Fainelli]

Hello,

On Monday 13 December 2010 07:53:07 Philip Prindeville wrote:
> I was trying to get this discussion rolling on linux-atm-general but didn't
> have much luck.
> 
> I was wondering what the downside to having ATM/DSL interfaces use
> net_devices would be?

I think you would have to add ATM/DSL-specific extensions (ala wext) just to 
extend it, specializing an atm_dev would make more sense to me.

> 
> Part of the reason for wanting to do this is to have an end-point to
> send/receive netlink messages to, so that the interface can report carrier
> state transitions, bit rates, bit-error rates, SNR, attenuation,
> constellations, transmitter gain, etc.
> 
> Seems simple enough.

If you want to be able to report informations from the DSL PHY, I would rather 
specialize an interface called, say dsl_phy which has a list of operations for 
setting/getting the DSL PHY state, low-level counters ... 

The atm stack more or less already supports an ATM PHY with 
atmphy_ops, but is in my opinion too limited to query chip-speficic infos.

Once that interface is well defined, adding netlink support to it should be 
rather straight forward.

> 
> Why not do this?
> 
> Thanks,
> 
> -Philip
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Using net_devices with ATM/DSL

[Philip Prindeville]

On 12/13/10 4:50 AM, Florian Fainelli wrote:
> Hello,
>
> On Monday 13 December 2010 07:53:07 Philip Prindeville wrote:
>> I was trying to get this discussion rolling on linux-atm-general but didn't
>> have much luck.
>>
>> I was wondering what the downside to having ATM/DSL interfaces use
>> net_devices would be?
> I think you would have to add ATM/DSL-specific extensions (ala wext) just to
> extend it, specializing an atm_dev would make more sense to me.

As long as it's symmetrical/consistent for br2684, PPPoE, and PPPoA, that would be good.

>> Part of the reason for wanting to do this is to have an end-point to
>> send/receive netlink messages to, so that the interface can report carrier
>> state transitions, bit rates, bit-error rates, SNR, attenuation,
>> constellations, transmitter gain, etc.
>>
>> Seems simple enough.
> If you want to be able to report informations from the DSL PHY, I would rather
> specialize an interface called, say dsl_phy which has a list of operations for
> setting/getting the DSL PHY state, low-level counters ...

Yes and no.  Carrier, bit rates, bit-error rates, are generic to ATM (because I might have an OC3c or OC12).

SNR, attenuation, constellations, transmitter gain, etc. are specific to DSL.


> The atm stack more or less already supports an ATM PHY with
> atmphy_ops, but is in my opinion too limited to query chip-speficic infos.

And I think it's only visible when you use br2684, right?  I also don't understand why the PPPoE code doesn't leverage br2684 more...


> Once that interface is well defined, adding netlink support to it should be
> rather straight forward.
>
>> Why not do this?
>>
>> Thanks,
>>
>> -Philip