Re: modem not responding

[Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>]

On Tue, Feb 01, 2005 at 11:00:47AM +0100, Jean Lee wrote:
> After a short study, it seems that the SOCs which are well suited for my 
> application are the AT91RM9200 and Cirrus EDB9302. For both chips, the 
> only available kernel with peripherals support is a 2.4 kernel. (and 2.6 
> kernels are unofficial ones)

I know that people have been on at Atmel for some time to do a 2.6
port for their AT91RM9200 device, but they haven't been interested
in that (for unknown reasons.)  That is rather unfortunate because
it means that AT91 support has been completely missing in 2.6.

That is starting to change now - there are initial patches becoming
available for 2.6 kernels, which presently seem to be a pure forward
port of the 2.4 code.  That's not to say that there's anything bad
about them - it's just a useful first step when you've been so behind
for a long time.

However, I think that integrating a lot of new features into existing
code is difficult to do, so I think it's going to be some time before
the AT91 based support itself becomes "stable" in 2.6 kernels.

As far as EDB9302 and other Cirrus devices - there isn't much to say.
Cirrus don't play with the open source community in a way which is
beneficial to them.  The only reason that 2.4 contained some Cirrus
support is because I had a platform for a couple of months upon which
I developed some of the support.  There were contributions from a few
other people to add support (but not maintain the support so it broke
over time) for other Cirrus SoCs.  So, essentially, Cirrus support is
very poor for any kernel, except the ones that Cirrus themselves decide
People Must Use.

That isn't the open source model at all - it's more like the developer
lockin which happens with closed source products.

> I don't think that I am an exception. A lot of project are now going 
> through linux because it is opensource and for a lot of people, it is 
> the same as free.

That is a very worrying statement.  If people are using it because
they think it's free, are they actually complying with the license
terms?  Are they even aware of the license terms?

It has been said by others that ramming the GPL down peoples throats
drives people away from Linux, but maybe it's driving people away with
good reason - the people being driven away may have no intention of
complying with its terms.  That isn't a bad thing.

> Conclusion :
> I think that the real problem is that the kernel is in transition : 
> There are real linux developpers who are working on 2.6 kernels and who 
> don't want to hear about 2.4 kernels because it is one year old for 
> them.

2.4 kernels are far older than one year.  2.4.18 (which is the version
which started this thread) was released Feb 2002 through to June 2002.
That's two and a half years old at least.

Obviously you can't expect free support for code which is 2.5 years old!

> But I think that there are a lot of people like me for whom the 
> current linux version is 2.4 BECAUSE of device drivers availability
> (and 2.6 is an experimental version)...

And there's that misconception again.  2.6 is not experimental - it is
a stable kernel.  People like Red Hat and SuSE have been shipping 2.6
kernels to their customers for a long time now.  The core of 2.6 has
been stable for since before 2.6.0 was released according to people
involved in the core kernel subsystem development.

Just because ARM developers won't put the time in to 2.6 to provide
the drivers for ARM developers to move forward does not make that
kernel version "experimental".

Also notice that there's an inherent vicious circle present.

1. people develop 2.4 to add more code
2. 2.6 doesn't contain this code
3. 2.6 thereby lags behind 2.4
4. people won't look at 2.6 because it doesn't contain the necessary code
5. people develop 2.4 to add more code
6. goto 2

Tell me - how do we break this vicious circle?  How do we solve this
problem?  Bear in mind that we don't have infinite resources, and
those who are looking at 2.6 are basically doing the best they can
already.

I think what we need are more people looking at and using 2.6 kernels
for your concerns to get addressed.  How do we achieve that?

> If someone doesn't want to deal with 2.4 kernels, he can simply not 
> reply (or just advice to go to 2.6 kernel and stop the support if the 
> answer is "impossible to move to 2.6 kernel")...

This is generally what I do today.  The end result is that I actually
don't reply to a lot of linux-arm-kernel traffic.  Maybe I should
unsubscribe from the mailing list and save myself the trouble of
looking at a lot of mail which doesn't interest myself (see below)?

> Once most basic device drivers ( if we can consider USB host as a basic 
> device driver) will be available for 2.6 kernels, the need for these two 
> sort of support will disappear (but will certainly appear between 2.6 
> and 2.8 kernels...). I'm sure that Darwin would have agreed.

Who is going to provide these basic device drivers?  If they haven't
been written by now, it's never going to happen.  If it's never going
to happen, that means that people will continue using 2.4 kernels.
In turn, that means we'll have a continuous stream of 2.4 questions
here.

This also means that the development work done on 2.6 kernels has been
a complete waste of time.  Therefore, maybe we should just pack our bags
and stop developing the Linux kernel right now and let it stagnate?
That's precisely what will happen if the talented people currently
trying to move this community forward get pissed off at those who are
holding the community back.

Either that or the "ARM Linux Kernel Cabal" (which unfortunately seems
to be quite real) disconnects itself from the rest of the "community",
which from my perspective is becoming more of a real possibility (see
http://www.linux.org.uk/Papers_CathPaper.cs)

Although both of those is a bit extreme, I wouldn't be surprised if
one of them becomes reality at some point.

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
FAQ/Etiquette:       http://www.arm.linux.org.uk/armlinux/mailinglists.php