netdev - Re: Using net_devices with ATM/DSL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4D0845B7.9050003@redfish-solutions.com>
Date:	Tue, 14 Dec 2010 20:36:07 -0800
From:	Philip Prindeville <philipp_subx@...fish-solutions.com>
To:	Florian Fainelli <florian@...nwrt.org>
CC:	netdev@...r.kernel.org
Subject: Re: Using net_devices with ATM/DSL

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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html