On Thu, 31 Mar 2011, Nicolas Pitre wrote:
On Thu, 31 Mar 2011, Linus Torvalds wrote:
What I'm _not_ seeing is a lot of cross-platform maintenance or sense
of people trying to reign things in and look for solutions to the
proliferation of random stupid and mindless platform code.
I do
On Thu, 31 Mar 2011, Linus Torvalds wrote:
On Thu, Mar 31, 2011 at 12:25 PM, Nicolas Pitre n...@fluxnic.net wrote:
So we need help! If core kernel people could get off their X86 stool
and get down in the ARM mud to help sort out this mess that would be
really nice (thanks tglx). Until
On Thu, Mar 31, 2011 at 06:49:11PM -0400, Nicolas Pitre wrote:
On Thu, 31 Mar 2011, Linus Torvalds wrote:
The only way to get quality code is to try to improve the quality from
the leaf nodes, because otherwise you'll always end up playing
catch-up. You'll get new bad code faster than you
On Wed, Mar 30, 2011 at 03:14:10PM -0700, Tony Lindgren wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [110330 14:05]:
And I have got to the point of just not giving a damn. I can't change
the ARM community (I've tried over the years to get more active review
of platform changes
On Thu, Mar 31, 2011 at 12:56:33AM +0200, Thomas Gleixner wrote:
On Wed, 30 Mar 2011, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [110330 15:22]:
On Wed, 30 Mar 2011, Tony Lindgren wrote:
One thing that will help here and distribute the load is to move
more things
On Thu, Mar 31 2011, Nicolas Pitre wrote:
Leaf nodes on ARM are people coming from corporate background with the
old school software development methodologies. They do it as a _job_
first and foremost. They only work on Linux because that's what their
boss assigned them to. Don't get me
On Friday 18 March 2011, Russell King - ARM Linux wrote:
I do get the impression that you're extremely unhappy with the way ARM
stuff works, and I've no real idea how to solve that. I think much of
it is down to perception rather than anything tangible.
Maybe the only solution is for ARM to
On Wed, Mar 30, 2011 at 10:06 AM, Arnd Bergmann a...@arndb.de wrote:
I'm still new to the ARM world, but I think one real problem is the way
that all platforms have their own trees with a very flat hierarchy --
a lot of people directly ask Linus to pull their trees, and the main
way to sort
On Wed, 30 Mar 2011, Linus Torvalds wrote:
ARM right now i a nightmare, and most of it is because ARM hardware
manufacturers are morons.
If in your mind competitors == morons then you might be right.
But the way the ARM tree is then laid out
has made that even more painful, and the decision
On Wed, 30 Mar 2011, Linus Torvalds wrote:
On Wed, Mar 30, 2011 at 10:06 AM, Arnd Bergmann a...@arndb.de wrote:
I'm still new to the ARM world, but I think one real problem is the way
that all platforms have their own trees with a very flat hierarchy --
a lot of people directly ask Linus
On Wed, Mar 30, 2011 at 1:41 PM, Nicolas Pitre n...@fluxnic.net wrote:
If in your mind competitors == morons then you might be right.
There's a difference between competition and do things differently
just to be difficult.
Trying to rely on bootloaders doing things right is like saying that
On Wed, Mar 30, 2011 at 07:06:41PM +0200, Arnd Bergmann wrote:
On Friday 18 March 2011, Russell King - ARM Linux wrote:
I do get the impression that you're extremely unhappy with the way ARM
stuff works, and I've no real idea how to solve that. I think much of
it is down to perception
* Linus Torvalds torva...@linux-foundation.org [110330 12:19]:
On Wed, Mar 30, 2011 at 10:06 AM, Arnd Bergmann a...@arndb.de wrote:
I'm still new to the ARM world, but I think one real problem is the way
that all platforms have their own trees with a very flat hierarchy --
a lot of people
* Thomas Gleixner t...@linutronix.de [110330 14:07]:
So one person will be not enough, that needs to be a whole team of
experienced people in the very near future to deal with the massive
tsunami of crap which is targeted at mainline. If we fail to set that
up, then we run into a very ugly
* Nicolas Pitre n...@fluxnic.net [110330 13:39]:
Trying to rely on bootloaders doing things right is like saying that x86
should always rely on the BIOS doing things right. We have this chance
in the OMAP case to have a manufacturer who is smart enough to document
all those things so
* Russell King - ARM Linux li...@arm.linux.org.uk [110330 14:05]:
On Wed, Mar 30, 2011 at 07:06:41PM +0200, Arnd Bergmann wrote:
And I have got to the point of just not giving a damn. I can't change
the ARM community (I've tried over the years to get more active review
of platform changes
On Wed, 30 Mar 2011, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [110330 14:07]:
So one person will be not enough, that needs to be a whole team of
experienced people in the very near future to deal with the massive
tsunami of crap which is targeted at mainline. If we fail
On Wed, Mar 30, 2011 at 2:44 PM, Tony Lindgren t...@atomide.com wrote:
That's ridiculous. It's entirely due to the whole f*cked-up arm ecosystem.
Yeh there's no BIOS and there are no scannable busses.. Which leads
to huge amount of data patches that show up in the diffstat.
Yes. And due to
On Wed, Mar 30, 2011 at 02:54:35PM -0700, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [110330 14:07]:
So one person will be not enough, that needs to be a whole team of
experienced people in the very near future to deal with the massive
tsunami of crap which is targeted at
* Linus Torvalds torva...@linux-foundation.org [110330 15:18]:
On Wed, Mar 30, 2011 at 2:44 PM, Tony Lindgren t...@atomide.com wrote:
But for ARM, I suspect even ACPI would actually be an improvement.
Because on ARM, the crazy non-platform hw people already happened, and
took over the insane
* Thomas Gleixner t...@linutronix.de [110330 15:22]:
On Wed, 30 Mar 2011, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [110330 14:07]:
So one person will be not enough, that needs to be a whole team of
experienced people in the very near future to deal with the massive
* Paul E. McKenney paul...@linux.vnet.ibm.com [110330 15:35]:
On Wed, Mar 30, 2011 at 02:54:35PM -0700, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [110330 14:07]:
So one person will be not enough, that needs to be a whole team of
experienced people in the very near
On Wed, 30 Mar 2011, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [110330 15:22]:
On Wed, 30 Mar 2011, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [110330 14:07]:
So one person will be not enough, that needs to be a whole team of
experienced people
On Wed, Mar 30, 2011 at 03:47:52PM -0700, Tony Lindgren wrote:
* Paul E. McKenney paul...@linux.vnet.ibm.com [110330 15:35]:
On Wed, Mar 30, 2011 at 02:54:35PM -0700, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [110330 14:07]:
So one person will be not enough, that
On Wed, 30 Mar 2011, Tony Lindgren wrote:
* Paul E. McKenney paul...@linux.vnet.ibm.com [110330 15:35]:
On Wed, Mar 30, 2011 at 02:54:35PM -0700, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [110330 14:07]:
So one person will be not enough, that needs to be a whole
* Thomas Gleixner t...@linutronix.de [110330 16:11]:
On Wed, 30 Mar 2011, Tony Lindgren wrote:
* Paul E. McKenney paul...@linux.vnet.ibm.com [110330 15:35]:
On Wed, Mar 30, 2011 at 02:54:35PM -0700, Tony Lindgren wrote:
* Thomas Gleixner t...@linutronix.de [110330 14:07]:
So
On Wed, 30 Mar 2011, Linus Torvalds wrote:
On Wed, Mar 30, 2011 at 1:41 PM, Nicolas Pitre n...@fluxnic.net wrote:
If in your mind competitors == morons then you might be right.
There's a difference between competition and do things differently
just to be difficult.
Absolutely. We've
On Wed, Mar 30, 2011 at 07:31:59PM -0400, Nicolas Pitre wrote:
Sure, but important noise nevertheless. As long as the noise is
confined to a limited set of .c files I'm happy. OTOH I have very
little hope for a separate project that would only deal with that noise.
That will simply never
On Wed, Mar 30, 2011 at 12:21:32PM -0700, Linus Torvalds wrote:
Look at the dirstat for arch/ in just the current merge window
(cut-off at 5% just to not get too much):
[torvalds@i5 linux]$ git diff -C --dirstat=5 --cumulative v2.6.38.. arch
14.0% arch/arm/mach-omap2/
5.8%
* Russell King - ARM Linux li...@arm.linux.org.uk [110330 16:57]:
On Wed, Mar 30, 2011 at 07:31:59PM -0400, Nicolas Pitre wrote:
Still, because ARM is just a CPU architecture, those SOC vendors will
always have something new to differenciate themselves from the other SOC
vendors. And
Nico:
On Wed, Mar 30, 2011 at 6:31 PM, Nicolas Pitre n...@fluxnic.net wrote:
But X86 is peanuts. Really.
Finally, a voice of reason!
On ARM there is simply not such thing as a single machine design to
clone, and a closed source test bench to design for.
... and there almost certainly
On Wed, 30 Mar 2011, Nicolas Pitre wrote:
On Wed, 30 Mar 2011, Linus Torvalds wrote:
On Wed, Mar 30, 2011 at 1:41 PM, Nicolas Pitre n...@fluxnic.net wrote:
Trying to rely on bootloaders doing things right is like saying that x86
should always rely on the BIOS doing things right.
No. Not
On Wed, Mar 30, 2011 at 5:15 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
In this merge window, I deleted at least 6000 lines from arch/arm, and
by quoting diffstat percentages, you're using that against the ARM
community. Why did I bother (that's not a question).
Umm. The
Linus:
On Wed, Mar 30, 2011 at 7:55 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
124022 total arch/sh
124418 total arch/sparc
181997 total arch/m68k
246717 total arch/mips
254785 total arch/x86
370912 total arch/powerpc
732732 total arch/arm
I'm not sure this metric is
On Wed, Mar 30, 2011 at 6:15 PM, Bill Gatliff b...@billgatliff.com wrote:
I'm not sure this metric is completely fair to ARM. If you want to
level the field, I think you have to divide each result by the number
of SoC's
But that's the problem with ARM. Hardware companies that do one-off
Linus:
On Wed, Mar 30, 2011 at 8:37 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
There's nothing good about causing extra work just because ARM hasn't
had the sense to standardize on one (or a couple) of interrupt
controllers etc.
You should go talk with ARM about it, I'm sure
On Wed, Mar 30, 2011 at 6:44 PM, Bill Gatliff b...@billgatliff.com wrote:
In the meantime, we have to live with the chips that exist and the
ones coming down the pipe. Until ARM and all their licensees start
consulting us on such matters, we'll just have to find a way to deal
with what we're
Linus:
On Wed, Mar 30, 2011 at 8:56 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
(a) we don't have to be stupid and think it's a good design and an
opportunity like you do.
The complexity that is the current state of the ARM ecosystem presents
the opportunity to find a way to
On Wed, 30 Mar 2011, da...@lang.hm wrote:
On Wed, 30 Mar 2011, Nicolas Pitre wrote:
Furthermore, this does create pain. you have to make things in sync
between the kernel and the mini-kernel (let's call it bootloader). In
practice the bootloader is always maintained separately from the
As long as SOC vendors keep producing wildly different architectures
besides the core CPU we'll have this problem. Denying the reality won't
make that problem go away either. And device tree won't stop those
vendor from still trying to do things differently (better?) because they
are not
On Wed, Mar 30, 2011 at 7:20 PM, Bill Gatliff b...@billgatliff.com wrote:
If it isn't opportunity, then you must be arguing that we shouldn't
add any new ARM SoC support to the kernel. Is that what you are
saying?
What I'm saying is that we should not be adding ANY MINDLESS BOARD
DRIVERS for
On Wed, 30 Mar 2011, Linus Torvalds wrote:
Umm. The actual stats are still:
1349 files changed, 62230 insertions(+), 33993 deletions(-)
which is sad. And the end result speaks for itself: this is lines per
architecture:
...
124022 total arch/sh
124418 total arch/sparc
On Thu, 31 Mar 2011, Dave Airlie wrote:
As long as SOC vendors keep producing wildly different architectures
besides the core CPU we'll have this problem. Denying the reality won't
make that problem go away either. And device tree won't stop those
vendor from still trying to do things
On Wed, 30 Mar 2011, Nicolas Pitre wrote:
On Wed, 30 Mar 2011, da...@lang.hm wrote:
On Wed, 30 Mar 2011, Nicolas Pitre wrote:
this means that you need to have some group doing the equivalent of assigning
device numbers for the different devices (and in this case going just a little
On Thu, Mar 31, 2011 at 01:31, Nicolas Pitre n...@fluxnic.net wrote:
On Wed, 30 Mar 2011, Linus Torvalds wrote:
The long-term situation should be that you should be able to have ONE
binary kernel just work. That's where we are on x86. Really.
But X86 is peanuts. Really. There was one
On Fri, Mar 18, 2011 at 9:09 AM, Tony Lindgren t...@atomide.com wrote:
* Linus Torvalds torva...@linux-foundation.org [110317 20:00]:
Make platforms that need it select it or something. It looks like
nobody but an OMAP4 could _possibly_ ever want to answer 'y' to that
question, SO DON'T ASK
* Ohad Ben-Cohen o...@wizery.com [110318 01:04]:
On Fri, Mar 18, 2011 at 9:09 AM, Tony Lindgren t...@atomide.com wrote:
* Linus Torvalds torva...@linux-foundation.org [110317 20:00]:
Make platforms that need it select it or something. It looks like
nobody but an OMAP4 could _possibly_ ever
Hi Linus,
Please pull omap changes for this merge window from:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
omap-for-linus
To summarize, this contains omap3 and 4 PM updates, new ti816x
processor support, changes many drivers to use common hwmod
platform code,
On Thu, Mar 17, 2011 at 11:30 AM, Tony Lindgren t...@atomide.com wrote:
Please pull omap changes for this merge window from:
Gaah. Guys, this whole ARM thing is a f*cking pain in the ass.
You need to stop stepping on each others toes. There is no way that
your changes to those crazy clock-data
On Thu, Mar 17, 2011 at 11:30 AM, Tony Lindgren t...@atomide.com wrote:
Please pull omap changes for this merge window from:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
omap-for-linus
Btw, that generic hardware spinlock thing needs to be hidden from
sane people
101 - 150 of 150 matches
Mail list logo
