There are a handful of "minor" ARM platforms in the mainline that haven't
been touched for as many as five years, Olof Johansson said in kicking off
a discussion of perhaps deprecating some of those platforms. The code for those
platforms gets updated whenever there are sweeping changes, but they may
not have been tested in years. They build just fine, but no active
developers have the hardware to actually test them. He wondered when or if
those platforms can
ever be removed from the tree.
He suggested that once device
tree has been proven as a solution for
reining in the explosion of board files in the ARM tree, perhaps a one or
two-year deadline could be set. Those platforms that don't update to use
device tree could then be dropped.
There are still lots of older ARM platforms that are supported;
OMAP 1 was cited as an example. Even though some in the discussion
were a bit skeptical about older chips running mainline kernels, that
does happen. There are hobbyists or others who keep the older chips
working. Thus, those are not targets for deprecation.
But, Tony Lindgren noted that OMAP 2 has some 30 different board files
and that there is "no way" those can all be converted to device tree. Arnd
Bergmann suggested that in cases like that, the drivers should be converted to
work with device tree and the board files should just be removed from the tree.
Users of those platforms can either continue using older kernels or create
device tree descriptions using the updated drivers.
That may not be possible in all cases. Lindgren mentioned that ARM
maintainer Russell King has an automated board test setup that could be
affected if those board files are removed. On some platforms, it may
require major work to get power management and other features
working with device trees. For legacy boards, it is unlikely that
anyone will actually do that work.
There is a question of how to decide which board files should be
deprecated, Lindgren said. A list of proposed deprecations should be
created. Some kind of tool that uses Git to find which platforms have not
been updated recently would be useful here.
In the discussion that followed, several different boards were mentioned as
candidates for deprecation.
Some participants spoke up for specific boards or
noted that King used them in his testing. That led to a joking suggestion
that someone find a way to surreptitiously relieve King of the burden of
some of those
The bcmring platform is particularly problematic because it was completely
broken for roughly two years, but has recently been picked up by some
hobbyists (who happen to work for Broadcom, creator of the platform). It
has a "horrible" OS abstraction layer, so it doesn't really belong in the
mainline in its present form. Will Deacon suggested that perhaps the platform
could be moved to the staging tree; a checklist could be provided for what is needed before it would be acceptable in the mainline.
For defconfig files, Johansson proposed that "superset configurations" be
created, which turn on every driver and feature that could be present on a
platform. Those can then be "whittled down" by board or SoC vendors as
needed. That will help increase the amount of build testing. Bergmann
agreed, saying that having 30 defconfigs was not really a problem, even if
only five are being used in practice. That would be a big improvement over the
130 or more defconfigs that are currently in the tree, Johansson said.
Specific platforms that were mentioned as targets for deprecation included
ks8695, h720x, l7200, netx, w90x900. In addition, ixp4xx was targeted for
deprecation, but that may still be a ways off.
to post comments)