Bug #321

ar71xx architecture needs to move into the kernel mainline

Added by Dave Täht on Dec 8, 2011. Updated on Apr 21, 2012.
New High Dave Täht

Description

we are using what is now a very stable, well tested, complete, set of patches for the ar71xx mips architecture. As are 34 other machine types. These patches are all currently out of tree, and trying to move forward in closer sync with the mainline kernel is a PITA. It wasn’t so bad until recently, but there has been a lot of churn in the stack in the 3.1 to 3.2 transition is making it hard to move forward.

… 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.

History

Updated by Dave Täht on Apr 21, 2012.

This is a static export of the original bufferbloat.net issue database. As such, no further commenting is possible; the information is solely here for archival purposes.
RSS feed

Recent News & Articles

Mar 21, 2019 Wiki page
Dave Taht's Take on TCP
Mar 17, 2019 Wiki page
Jake Holland's Stance on ECN
Sep 6, 2018 Wiki page
Pete Heist's Thoughts on ECN
Sep 5, 2018 Wiki page
Dave Taht's Stance on ECN
Sep 4, 2018 Wiki page
Jonathan Morton's Take on ECN

Find us elsewhere

Bufferbloat Mailing Lists
#bufferbloat on Twitter
Google+ group
Archived Bufferbloat pages from the Wayback Machine

Sponsors

Comcast Research Innovation Fund
Nlnet Foundation
Shuttleworth Foundation
GoFundMe

Bufferbloat Related Projects

Congestion Control Blog
Lede Project (OpenWrt)
Flent Network Test Suite
Sqm-Scripts
The Cake shaper
AQMs in BSD
IETF AQM WG

Network Performance Related Resources


Jim Gettys' Blog - The chairman of the Fjord
Toke's Blog - Karlstad University's work on bloat
Voip Users Conference - Weekly Videoconference mostly about voip
Candelatech - A wifi testing company that "gets it".