Merge window opens, kgdb merged
Posted Apr 18, 2008 23:38 UTC (Fri)
by intgr (subscriber, #39733)
[Link]
Posted Apr 19, 2008 4:41 UTC (Sat)
by gdt (subscriber, #6284)
[Link] (1 responses)
At the kernel miniconf at linux.conf.au Linus poked his head through the door just as debuggers were being discussed. After some "naughty schoolboys being discovered by the teacher" laughter over the coincidence of the timing it was plain that an elegant debugger patch might be accepted, and that some of the attendees were determined to create such a patch. It was also plain that Linus wasn't convinced about a debugger's usefulness in creating good code, but accepted that many people whom he respects were convinced.
Posted Apr 19, 2008 13:28 UTC (Sat)
by willy (subscriber, #9762)
[Link]
Posted Apr 19, 2008 15:20 UTC (Sat)
by muwlgr (guest, #35359)
[Link] (4 responses)
Posted Apr 19, 2008 15:36 UTC (Sat)
by rvfh (guest, #31018)
[Link] (3 responses)
Posted Apr 19, 2008 17:12 UTC (Sat)
by mingo (guest, #31122)
[Link] (2 responses)
Posted Apr 19, 2008 19:58 UTC (Sat)
by rvfh (guest, #31018)
[Link] (1 responses)
Posted Apr 19, 2008 22:55 UTC (Sat)
by adobriyan (subscriber, #30858)
[Link]
What errors are you talking about?
Nastygrams that even checkpatch.pl itself calls "WARNING"s?
Posted Apr 19, 2008 18:26 UTC (Sat)
by Felix_the_Mac (guest, #32242)
[Link]
Posted Apr 19, 2008 22:09 UTC (Sat)
by joib (subscriber, #8541)
[Link] (6 responses)
Posted Apr 19, 2008 22:54 UTC (Sat)
by sbergman27 (guest, #10767)
[Link] (5 responses)
Posted Apr 20, 2008 1:37 UTC (Sun)
by rsidd (subscriber, #2582)
[Link] (4 responses)
Posted Apr 20, 2008 6:23 UTC (Sun)
by Cato (guest, #7643)
[Link] (3 responses)
Posted Apr 20, 2008 7:59 UTC (Sun)
by trey (guest, #37500)
[Link] (2 responses)
Posted Apr 20, 2008 8:48 UTC (Sun)
by joib (subscriber, #8541)
[Link] (1 responses)
Posted Apr 22, 2008 12:46 UTC (Tue)
by knan (subscriber, #3940)
[Link]
Posted Apr 19, 2008 22:54 UTC (Sat)
by linuxbox (guest, #6928)
[Link]
Posted Apr 20, 2008 20:34 UTC (Sun)
by nowster (subscriber, #67)
[Link]
Merge window opens, kgdb merged
Wow, looks like the hell did freeze over!
Linus and kernel debugger at lca2008
Linus and kernel debugger at lca2008
Ice cream for everybody!
Merge window opens, kgdb merged
It seems that x86 tree gets bloated (look at 117->136 KLOC step).
Where are those famous code removers, so praised in LWN articles ?
Would be great if they get their hands at the issue ... :>
Merge window opens, kgdb merged
My thought exactly: I was expecting the merge to _reduce_ the code by, say, 20-30%...
Any knowledgeable person care to explain?
Merge window opens, kgdb merged
the linecount jump in the code-quality table was because KVM was merged into the x86 tree
under arch/x86/kvm/ and the lguest code was merged under arch/x86/lguest.
also, we've got a new sub-architecture, more debug features such as kgdb, etc. etc. - each of
which is extra code.
Since v2.6.24-rc1 (which was the first big unification step with 600 unification patches)
there were more than 1600 commits in arch/x86/. Every time we reduce size with a unification
some new feature eats it up ;-)
All in one: life didnt stop with unification :-)
Merge window opens, kgdb merged
Thanks a lot :)
Doesn't this mean that the error/kloc figure is a bit biased then? Although the conclusion
remains the same: it decreased.
Anyway, I do trust you clever people do the Right Thing, as the quality of my environment as a
whole clearly shows.
I just love Linux :)
> Doesn't this mean that the error/kloc figure is a bit biased then?
Merge window opens, kgdb merged
kmemcheck and ftrace
It looks like some other useful stuff is there too.
Am I right in thinking that the ftrace (latency tracer) patch has been merged?
Merge window opens, kgdb merged
As an aside, who makes 4096-way x86 machines (mentioned in the link about the x86 changes)?
They must be pretty specialized machines, as with 40-bit physical addresses, which is what is
found in current x86-64 cpu:s, they are limited to 1 TB total, or 250 MB/CPU.
Merge window opens, kgdb merged
SGI Altix, I would think. A terabyte is a terabyte. Each processor can address any part of
it. That's ram, of course. The architecture allows for 52 bits of virtual, or 4096 terabytes
of that.
There are, however, other difficulties to be overcome:
http://lwn.net/Articles/229873/
Merge window opens, kgdb merged
As far as I know, SGI Altix is based on Itanium, not x86. I haven't come across an x86
machine with more than 32 processor cores (8 socket, 4 core Barcelona).
Merge window opens, kgdb merged
SGI systems include x86 versions with this CPU count - for example, NASA recently bought an
Altix ICE blade server with 4096 Xeon CPUs:
http://www.sgi.com/company_info/newsroom/press_releases/2...
However, the line between this blade-based system and traditional Altix systems is not
entirely clear, though presumably with the right problem a blade server would be just as good.
Merge window opens, kgdb merged
Not a single system image (SSI). Imho runs multiple instances of Linux kernel.
Big shared-memory x86 machines
That's correct, Altix ICE (and Altix XE) are clusters. Each 2-socket node runs its own kernel,
and there is no shared memory between nodes, so inter-node communication is with message
passing (MPI).
AFAIK all big shared-memory machines SGI makes are Itanium-based.
I suspect the answer to this conundrum is that this changeset just increases some previous
x86-only max-cpu limit, and the mention of 4096-way machines refers to the Itanium-based SGI
Altix.
Big shared-memory x86 machines
There are development going on inside SGI for future and one-off machines, you know. The patch
came from a SGI employee, and definitely is for x86-64. While their current big boxes are
IA64, future machines doesn't need to be...
Merge window opens, kgdb merged
The BSDs have their KGDB equivalent, and the self-contained DDB debugger as well. For Linux,
the equivalent seems to be KDB. I'd enjoy seeing that cleaned up and merged.
Merge window opens, kgdb merged
The latest git updates (post 2.6.25) fix ath5k's symbol problems.