OpenWrt Meeting - June 26, 2015

Jump to: navigation, search

Attendees: Eric, Hauke, Paul, Vivek, Art, Kathy


  • working on tutorial for installing OpenWrt the first time
  • tentative date for OpenWrt summit on Oct 8 (day after ELCE)

Another idea for ELCE (Eric sent a separate e-mail with longer list already):

  • synch/planning of OpenWrt stable release kernels with respect to LTS kernels and what industry should be doing to help with collaboration and maintenance


  • sent several interesting links in a separate e-mail (that came up during discussions below)
  • Lantiq moved to OpenWrt as internal baseline development/distribution about 5 years ago
  • challenges for industry use of OpenWrt occur when a lot of code is changes or replaced, but not sent upstream. By default, proprietary packages are difficult to maintain because they aren't upstreamed.


  • Ikanos migrated to OpenWrt based distribution and build system a few months ago (from build root)
  • challenging to bring up OpenWrt on Ikanos platforms if core MIPS kernel releases are not in sync with kernel version used by OpenWrt
  • currently using OpenWrt BB as baseline
  • intend to upstream code to and OpenWrt but developers need to be allowed enough time to do that
  • challenges arise in isolating software into modules so that internal software is easier to upgrade to new OpenWrt versions
  • when Ikanos platforms include QCA Wi-Fi, integration of drivers and other software becomes easier when both companies use OpenWrt framework

Eric asks why upstreaming is separate from OpenWrt-based platform development. All on the call agreed that if companies performed upstream development first, then it would reduce overall development cost and greatly improve maintenance. What is the barrier? Typically lack of upper management understanding of the importance of upstreaming and direct project collaboration. Paul:

  • If you don't care about supporting code a year later, you push out your patches and move on. But if you want to be seen for code quality, then you want to push your code upstream because it will improve the quality (better high-level review) and reduce long-term maintenance costs. Also enables you to get forward compatibility "for free".
  • can look at git history to get a sense of code development cost and complexity. Linux kernel git enables this type of analysis.

Cost of not upstreaming? Hauke: Can track migration costs when updating from kernel x to kernel y. Paul: Many companies that Codethink has worked for have not been aware of these costs because they don't do detailed tracking of what their engineers are doing. They don't see where the effort is going. Art:

  • Wondering if prpl should buy and distribute some of the newly announced Cavium/ITUS platforms for development by the OpenWrt community. But what does the community need/want?

Board farm

  • installing various OEM and reference platforms into a remote access board farm with controllable power and serial console would be another good approach -- advantage of board farm is that it allows access by many different developers.
  • another benefit of a board farm would be regression testing. Automatically flash platforms with trunk (daily) and run a suite of tests.
  • Linaro - already testing a variety of platforms against Linux-next kernels (the build server software is AGPL so we can look at what they are doing). Perhaps prpl can help facilitate similar types of testing for additional platforms (anything that can run OpenWrt).