Russell:
There is the converse though - we can't support 2.4 for ever, which is
what people would like us to do. We have to cut it off sometime, and
I think that time is very close, if not now.
I totally understand the situation. You can't get eyeballs on 2.6 when
everyone is looking at 2.4. But for the existing systems running on
2.4, there's no other choice.
I disagree, there's certainly nothing preliminary about it. 2.6 is
now over two years old and is most definitely mature by my standards.
I'm not going to comment on the AT91 situation because I think that's
something of an annoying special case. However, other SoC support is
in 2.6 and "Just Works."
I'll have to get back to you on that one, but I think our standards of
"definitely mature" may differ. I for one look for more that CPU
instruction set and MMU support.
As for the LH7xxxx stuff, the support in 2.6 is 8 months old. If you're
really telling me that it takes more than 8 months to stabilise support
for a chipset, then there's something wrong somewhere, and it isn't the
kernel.
The kernel definitely contributes, what with all the instability in APIs
particularly where SOC peripherals are concerned. I know that a lot of
that can't be helped, but it is definitely something that creates a lot
of work.
And 8 months isn't unreasonable, especially when we all realize that
within those months someone will come along and tweak something that
breaks all the previous work--- driver APIs being on that list.
If for every time you said, "everyone should start using this new API"
you actually did some code to make that happen, that would be a great
start. I mean for more than one or two targets. I'd even pony up for
the hardware.
Seriously. I'm trying to help myself and san-people (and a lot of
others, judging by my inbox) with AT91RM9200, but as soon as I get
2.6.10-rc2 working then along comes 2.6.11 and now even 2.6.10 is
rendered "obsolete" (even though I don't think the differences matter)
. Either slow down, provide a clear and workable migration path, or get
what we have now.
And I don't think AT91RM9200 is a rare exception, although it may have
more problems than other targets. How many ARM SOC targets have
*complete* peripheral support in any 2.6 kernel? If it isn't a short
list, I'll publically apologize for not being able to stay on top of
what's been happening lately.
[Those of you who know me know that I *have* been dealing with some
serious personal matters that have kept me away from the computer more
than I would like for the last two years, but not to the extent that I'm
now irrelevant, methinks.]
What it basically comes down to is a short sighted attitude by people
who use a policy (develop on 2.4) to provide an argument (2.6 doesn't
contain what we need) to reinforce that policy (develop more on 2.4).
It's a vicious circle.
I totally agree. And I don't know of another workable, current solution
besides (a) dropping 2.4, as you propose, or (b) setting up something
resembling a fork of the kernel sources and mailing list, and handing
off support to a different team (which you also appear to propose).
Neither solution is perfect in the ideal world, but unfortunately ideal
!= real.
One way to break that cycle is to provide 2.6 kernels with full
peripheral support, something I'm trying to do for AT91RM9200. Then
it's a lot easier for someone to move to the later code than it is now.
Maybe the way to break this once and for all is to split this list so
that obsolete 2.4 stuff ends up on linux-arm-kernel-obsolete, so that
those of us who wish to move forward can do so without having to
constantly waste our time reading messages about obsolete kernels.
IF we were talking about 2.2 and 2.0 kernels, I'd agree with your
characterization here.
Consider it a fork of the community into those who wish to reap the
benefits and contribute back of open source vs those who wish to stay
in the previous "mature" century and leach off the hard work put in by
a relatively small number of community players.
I totally, totally disagree with the context you're trying to establish.
I've been doing embedded Linux for nearly as long as you have, and I can
tell you from direct, firsthand experience that there is a silent
majority out there using this stuff to make a living who are so totally
overworked with dealing with the issues needed to get linux-arm into
production-ready status, they don't get the privilege of tweaking a few
lines here and there and calling everything else "obsolete".
This same, silent majority has dragged me to multiple continents to help
deal with the mess that declaring stuff "obsolete" has caused. That
same, silent majority is even begging me to write a book to document the
state of Linux for embedded work, and I can't even do that because
there's nothing resembling a solid foundation to document from.
I'll respond to your refering to me as a "leech" by suggesting that
Those Who Change Things Because They Can really make life difficult for
Those Who Have To Get Stuff Working To Make A Living. And community
players fall squarely into both camps.
The fact that you don't always hear from both camps could be because
we're leeches, but could also be because we've got our heads down, working.
Look, we're all learning how to do this stuff better, even you. That
doesn't mean that we're leeches and it definitely doesn't mean that we
aren't community players. It does mean that we can't all stay in
lockstep. But that doesn't give anyone the right to casually throw out
terms like "annoying", "leeches", and most of all, "obsolete".
(If anyone finds any of this offensive, I'm sorry. A line has to be
drawn at some point.)
Draw the line, feel free. In fact, it probably makes sense to. But
when you do, I'd appreciate it if you would announce who the new "THE
developer of ARM Linux (for 2.4)" ends up being.
b.g.
--
Bill Gatliff
Professional embedded GNU training.
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]
