Nico, Russell:
Guess who was having a bad day today (hint: me!). Before I go any
farther, please accept my apologies for being both generally inflamatory
and inappropriately broad in my rant.
I think absolutely _no_ kernel ever had a _complete* peripheral support
for any ARM SOC.
True, but I think some have been really close. But less close in 2.6
than in 2.4. Note that I haven't done an exhaustive examination, please
correct me if I'm wrong.
I think there is way more people keeping up with 2.6.x development then
people actively maintaining 2.4.x. I agree it might be hard to see from
your position though.
A lot of my work lately has been in maintaining existing projects, all
of which are running 2.4.x. There's strong inertia to stay with
something circa a kernel that works; jumping ahead two years to a 2.6
kernel, complete with the changes required to existing 2.4 drivers, is
more than many of my clients can deal with.
Come on. Such a statement makes me believe you're in fact not able to
grasp the whole picture.
Some days I can do it better than others, I'll grant you that!
But look at it from my perspective: I produce a board support package
for a client, based on a particular kernel that's pretty current at the
day of the release. They take it in-house, hack away on it for their
application, then come back six months later asking for a fix for
such-and-such problem, or additional driver support. It's a difficult
response to say, "well, that's obsolete now, you have to move to the
latest kernel before I can help you".
If you'd put the same amount of effort into making your stuff work in
2.6 as you do with 2.4 now you'd probably have the benefit of watching
_other_ people modify your _own_ code to make it work with any API
changes that are happening in the kernel. End result: you would have
support for your target in the most advanced kernel to date, including
free security updates and performance improvements.
I try to put an equal effort into *both*! Producing new board support
packages based on the latest-and-greatest, but also keeping older stuff
alive for clients who have a lot invested in their existing projects.
Now you sticking to 2.4 only risk seeing yourself more and more isolated
from the most talented kernel developers who moved onto more interesting
things and the maintenance costs will increase for _you_ since you'll be
alone to do all the work and assist those who rely on you for their own
living. Can't you see it is a dead end?
Of course it's a dead-end, that's what everybody is after. But in the
transition to death, there is a lot of important work that still has to
get done. And I'm mostly whining about the 2.4-2.6 transition, which we
all knew was coming ---including me--- and just had to live with.
But even given that, it pains me every time the response to a 2.4.x
question is something along the lines of, "sorry, you'll have to move to
2.6-x-y before anyone here will help you". That simply isn't a
realistic solution for a lot of people.
And what will you do when those big embedded companies will release
their offering on 2.6.x showing how better it is (and it really is,
trust me) and suddenly your own customers will notice and ask for 2.6.x
too? You'll have wasted so much time on 2.4 and got so far behind on
2.6 that you'll have nothing to content your customers who will turn to
someone else with 2.6 support.
Well, I'm working on 2.6 offerings too! But some people need stuff
finished before they can start on other stuff, and when a 2.4.27-vrs1
kernel is 99% there, it doesn't make sense to push them to 2.6. In the
case of AT91, nearly every SOC peripheral works in 2.4.27-vrs1; most of
them don't in 2.6. I'm not sure it's unique in that regard (maybe I'll
find out it is, I have PXA, MX1 and other ARM projects coming up shortly).
But if... only if you'd put the minimum effort to keep up with 2.6...
Believe me, if a "minimum effort" were all that was involved, I'd be up
to it!
One thing I haven't been doing a good job of is utilizing the ARM-linux
patch system, which allows me to push more of what I'm doing into the
mainstream. That's something I'm resolving to do better in the near
future. But many of the changes I'm making are for specific hardware
that isn't generally available, so even on the best of days, I still end
up with kernels that are "stuck in time" at a particular revision.
Yeah Right. Changes do happen in 2.6.x just to screw people up. This
is what kernel developers enjoy the most.
After I read my post, I pretty well concluded that I had completely run
off the rails at that point. Sorry!
b.g.
--
Bill Gatliff
bgat@xxxxxxxxxxxxxxx
-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
FAQ/Etiquette: http://www.arm.linux.org.uk/armlinux/mailinglists.php
[Site Home]
[IETF Annouce]
[Security]
[Bugtraq]
[Linux]
[Linux ARM Kernel]
[Linux MIPS]
[ECOS]
[Tools]
[DDR & Rambus]
[Monitors]
