[lkml]   [2006]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Development tree, PLEASE?

--On January 20, 2006 8:25:34 PM +0000 Russell King
<> wrote:

> On Fri, Jan 20, 2006 at 10:14:15AM -0700, Michael Loftis wrote:
>> It's easier for an embedded system especially to pick a target, and then
>> stay with it. Later when a new major version comes out the time can
>> then be invested ONCE to redevelop what needs redeveloping, which is
>> easier to do (yes I'm speaking from a business standpoint, sorry, but
>> someone has to) and to sell to management than nickel-and-dime to death
>> of trying to follow a development tree.
> Please note that the current development strategy suits embedded folk.
> With the old model, embedded folk could not wait two years for a (eg)
> 2.5 kernel to become a 2.6 kernel and then "stabilise". In two years,
> the new SoC is already in full-use in multiple applications and folk
> have been and long gone developing their products.
> So what happens is a massive conflict of interest - do we put
> $mass-of-new-features into 2.4 kernels at the risk of destabilising
> the current users, or do we push it into 2.5 and wait two or more
> years before folk start using that code.
> Like it or not, the latter causes a _lot_ of difficulties for a _lot_
> of people, so much so that it's an economic disaster unless you're a
> large corporation. The former is also a non-starter because then you
> end up with folk complaining that it should be in the development
> branch. It's a no-win situation - you can't satisfy everyone.

Yeah this is true.

> So, our current model is a compromise - you get _told_ that things
> will change well in advance, and if you choose to ignore those warnings
> (or don't respond to them) that's entirely your own problem.

I guess part of the problem is this process is still relatively new and all
the pointers I'm used to no longer apparently apply.

> It's like a stick and carrot scenario - see
> The carrot in this case is the notice about devfs removal. The
> stick is the actual devfs removal. One's pleasant, the other isn't.
> Which you take notice of is entirely your choice.

In atleast one case of my scenarios it's not heh. I've no choice but to
take 2.6.15(.x) but I have to build custom debian installers and maybe
still bring in newer e1000 sources from intel (still awaiting that build to
finish to find the results of that) but there's issues with devfs there
too, the only machine capable of testing needs devfs to boot and mkinitrd
fails miserably at the moment, and I'm not sure why, which I am
investigating more fully as well.

Like I said the problem from my point of view is needing a few trivial
changes, but having to take a whole new ball of wax, and all the testing
and verification work that takes for the hosting environments (maintaining
multiple kernels internally was long ago given up because it's impossible
to keep track of easily) here because we have to go completely away from
the vendor kernels and for the places where I'm maintaining embedded
(admittedly mostly x86 devices are my primary responsibility, though lately
I've been signed into a few ARM projects) though is the most painful since
there is a need to track the current kernel with bugfixes, and there's no
vendor to act as a buffer, and no central place to find these
updated/patched kernels which also measns if we make changes that cause us
to become a fork we might be legally bound to atleast provide a patch for
the core portions under GPL.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-01-20 23:08    [W:0.139 / U:0.268 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site