Hello,
On 01/23/12 02:34, Philip Prindeville wrote:
On 1/21/12 1:18 AM, Lee Essen wrote:
On 20 Jan 2012, at 23:47, Philip Prindeville wrote:
I'd sure like to see netlink being used to communicate speed/carrier changes up
into userspace.
Unfortunately there's absolutely no netlink support in the lantiq driver and I
don't think any of that info is available elsewhere, I would have thought
trying to add a netlink capability would be a bit extreme? (and probably well
outside my capability) … and that would then need to be done for every
subsequent DSL driver to maintain standardisation.
There is an ioctl interface, which also works without the daemon running, which
I did consider, but my thought was that this would require an extra binary to
maintain (unless there's a simple lua ioctl interface, but I couldn't find one)
and would have a lot less transparency than a script -- but I'm happy to knock
something up to make use of this if it's considered a better approach.
Regards,
Lee.
There aren't that many DSL flavors out there... Danube, Solos, Viking... that's
probably 90% of the market I'm guessing.
You missed all the BCM63xx SoCs, which represent 90% of the DSL market
actually, though their drivers are not opensource which is why people
tend to forget about them.
Once it gets done for one architecture, I'm sure someone on the linux-atm
mailing list would port it to others. I might do it for the Solos if I have a
working example of the netlink portion, then I can figure out how to
interrogate the hardware for link quality changes.
Having a generic DSL stack in Linux will be quite some work from an
acceptance perspective because:
- there are not only DSL ATM drivers in Linux (e.g: SoNET), and they
need to be supported too by this stack
- there is only one "modern" DSL/ATM driver right now which is solos, I
am not sure Lantiq has any plans for mainlining their driver, rewriting
ar7-atm to fit into that model is also a lot of work
Anyway, if you got that way, I think you could use generic netlink in
order to avoid the complexity of netlink and still have something useful.
--
Florian
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
