Re: modem not responding | |
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] | |
Executive summary:
You alledge that I'm making API and major changes throughout the whole
kernel, which makes your life difficult. I claim that to be false, and
I kindly request some examples.
On Mon, Jan 31, 2005 at 10:38:22AM -0600, Bill Gatliff wrote:
> 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.
Indeed, and neither can we get developers on to 2.6 because they're
developing on 2.4, helping to provide fodder for the "but 2.6 doesn't
do what we need" argument.
> 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.
The kernel doesn't support instructions sets. It may be true that
2.6 supports the newer MMUs, but that's only something really small.
> >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.
I think I must be having trouble remembering. What instability are you
referring to here?
There have been a few minor changes to the way that boards are supported:
- the system timer API (which was propagated to all merged board support)
- the addition of INIT_MACHINE (optional feature, you don't even have
to think about that when moving forward)
- moving (and I do mean just moving, no code changes) debug code into
include/asm-arm/arch-*/debug-macro.S
- moving (and I do mean just moving, no code changes) entry IRQ code
into include/asm-arm/arch-*/entry-macro.S
That's all I can remember, and they're all minor and very localised in
nature.
SOC peripheral APIs? Sorry, you've got me there. There's the device
model, and that's been stable and hasn't changed since before 2.6.0 was
released.
> 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.
8 months _is_ unreasonable. The lifetime of a product may be far less
than 8 months. If you're saying that you can't get stable support for
a SoC for a product developed within 8 months...
> 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.
Oh, you mean like what happened:
- for the system timer API.
- for the debug-macro.S split.
- for the entry-macro.S split.
I therefore think your comments are completely off the mark and aren't
really informed. However, if you think differently, please provide
examples and I'll be happy to eat my words.
> 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.
Three points here:
* Please list the changes between 2.6.10 and 2.6.10-rc2 which affect
you so others know the difficulties you're experiencing. Don't expect
others to read your mind.
* I don't control mainline kernel release dates, nor the other changes
which go in.
* People are far happier to support 2.6.10, even 2.6.9 when 2.6.11 is
available because they're all fairly closely related to each other,
and within a reasonable time to work out if a bug is still present.
A couple of further points to consider:
* how do I seem to maintain 80% of the existing platform support in the
kernel by doing precisely nothing?
* the recent problem with the firewall
A) I got the "2.6.10-rc2-bk1 fixes a problem you're seeing, please
upgrade" response and I did precisely that (without whinging I
might add). Took no time at all and fixed the problem with this
version.
B) the problem I was trying to fix - I investigated it, tracked it
down to where I thought it was. The networking people agreed,
produced a patch, and the result is running now. The result is
also in mainline - less than 24 hours after it was discovered.
Now, I will say that I know very little about the Linux IPv4 code.
However, this is how open source works. Notice any difference
between this and how it works here?
> 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.
That's actually a question which I'm in no position what so ever to
answer. Are you expecting me to download all the SoC data sheets and
work it out?
Also, it isn't up to _me_ to provide this support. Unless you're
implying that I should spend all my free time working for free to
produce all the drivers for hardware I don't have? That seems to be
what you're implying.
The only people who can really answer this question are the SoC
developers themselves, and I ask that they speak up.
> >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".
Please detail these issues. It would help things a lot more if more
people shared patches and such like on this mailing list - such as a
development list would be, rather than the list being used as a support
forum. This means that everyone benefits.
> 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.
There's plenty of books already - have you seen Karim's "Building
Embedded Linux Systems" book?
> 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.
Ben Dooks does a wonderful job at "those who have to get stuff working to
make a living". However, Ben is also a community player who sends me
patches almost on a daily basis since about July 2004. He seems to be
able to make a living, look after S3C2410, and feed back the fixes.
In fact, Ben is operating just like anyone else would do in the
mainstream Linux community. You may remember Linus' well known mantra:
Release Early Release Often. That's precisely what Ben is doing and
Ben is reaping the benefits of that.
Ben's been soo good at it that I hardly ever look at his patches
before merging them anymore - in fact, there's now only a day or so
between Ben sending a patch and it getting into mainline.
> 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.
Sorry, I think you're awfully confused. I'm not the 2.4 kernel developer,
and I haven't been for about two years now. Did you miss the announcement
made by the new developer?
-------------------------------------------------------------------
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]