… And it’s good, bufferbloat related churn, that we want to take advantage of.
There are a ton of drivers (and at least two duplicates) in the current patch set. The biggest problem in getting it into the kernel is that how machines are handled needs to adopt device tree support across the board, as Felix writes here:
“I think it does not make much sense to try to integrate the code from
our ar71xx into ath79 and pushing that upstream. The mips-machine way
of
supporting different boards with one kernel is somewhat cumbersome, a
much better way to deal with it is adding device tree support and using
that. Proper device tree support is currently being worked on for the
lantiq target. Once that’s functional, I’ll look into adapting it to
ath79 as well.”
What caused me to throw in the towel on getting rc7 out the door was that the move from 3.0 to 3.1 broke stuff, and the move to 3.2 was going to break it badly.
So a step back to do the engineering right here would be helpful.
(and personally, after going from kernel 2.6.37 to 3.1 over the course of this project, I’m really tired of having all these patches to deal with, that are very basic in many respects. What breaks most of the time is merely the Kconfig and Makefiles)
If we want to stay in sync with the kernel and move forward more rapidly in sync with it, spending some time to get more of this stuff in the kernel would be best. Bits and pieces of various drivers could go in incrementally… and I’d like to be thinking about exposing QoS features in, for example, the switch, better than they are now.
There are presently 63 ar71xx specific patches required to build openwrt/cerowrt for the ar71xx, and that doesn’t count the 160 machine and driver specific out of tree files.
I would like to have a grip and a estimate on the scope of this part of the project, as for the time and costs involved. I have a very good idea how much it costs not to do it, at this point.