Re: Stop the Linux kernel madness

[Tim Bird <tim.bird@am.sony.com>]

Jan-Benedict Glaw wrote:
> On Fri, 2004-06-18 08:13:15 -0700, William Lee Irwin III
> <wli@holomorphy.com>
> wrote in message <20040618151315.GC1863@holomorphy.com>:
> 
>>On Fri, Jun 18, 2004 at 10:43:19AM -0400, Rik van Riel wrote:
>>
>>>Yes, this is a hint at certain embedded developers.  You
>>>know who you are and chances are you also know what you would
>>>like to develop if you no longer had to spend your time porting
>>>the same old patches from one version of the product to the next.
>>
>>The shame of things is that the economic/effort problem appears to
>>often be "solved" by never migrating to new kernel versions, or
>>otherwise by amortizing the work involved with infrequent migrations.
> 
> Unfortunately, you're *very* right on this. Eg. read the linux-mips list
> (at linux-mips.org). You'll see that this list is often hit by people
> having problems. Normally, they hack on kernels like 2.4.16 or the like.
> These are totally unrelated projects, people and companies. I can't find
> words for that. They're missing a year of development and even feel sane
> with it. That's what vendors gave them...

It is good to see this issue discussed on LKML.  (It shows a
recognition of issues I deal with in my space every day.)
There are indeed armies of developers who work on Linux, but
who are stuck in version backwaters.  These developers almost
never visit or contribute to LKML.  The reasons for this
situation are numerous, and not easily solved with a wave of
the "just contribute stuff" wand.

One important factor is that very often the people
directly responsible for code generation in the embedded space
are simply not available for interfacing with the community.
In the embedded space, there is
tons of fragmentation and very little network effects between
developers.  There are language problems, culture problems,
legal problems, and an array of factors which create barriers
for developers at major CE companies contributing to Linux.

At the CE Linux Forum, we are trying to reduce or eliminate
some of these barriers, but it is difficult.

Realistic ideas for reducing these barriers are very welcome.
Believe it or not, most CE companies I work with WANT to
contribute back, but have a very difficult time with the details.

Here's a shameless plug:  I'm having a CELinux BOF at OLS to discuss
this and other issues.  It's the night of Wednesday, July 21.
Anyone can drop by if they are interested in this topic.
> 
> There's a lot of Linux beyond LKML, with a common problem: outdated
> source trees, with a shitload of patches. Linus could need another
> hacker or two working full-time on reviewing / importing those patches!

The idea of having some dedicated developers perform this function
is actually a pretty good one, although I wouldn't burden Linus
with managing them.  That is, it might be useful to have some people
following behind embedded product developers trying to glean,
generalize, forward-port and otherwise clean-up patches that
would otherwise never see the light of day.

=============================
Tim Bird
Architecture Group Co-Chair
CE Linux Forum
Senior Staff Engineer
Sony Electronics
E-mail: Tim.Bird@am.sony.com
=============================