| |||||||||||||
Merge window opens, kgdb merged
The 2.6.26 merge window has opened; one of the first things to go in was
the massive x86 tree. What
really caught your editor's attention, though, was the merging of kgdb for
the x86 architecture. Linus Torvalds's aversion to
debuggers has kept the mainline free of interactive debugger support
(on x86, at least) since the
beginning, forcing developers wanting debugging support to apply external
patches. That will finally change in 2.6.26.
(Log in to post comments)
Merge window opens, kgdb merged Posted Apr 18, 2008 23:38 UTC (Fri) by intgr (subscriber, #39733) [Link] Wow, looks like the hell did freeze over!
Linus and kernel debugger at lca2008 Posted Apr 19, 2008 4:41 UTC (Sat) by gdt (subscriber, #6284) [Link] 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.
Linus and kernel debugger at lca2008 Posted Apr 19, 2008 13:28 UTC (Sat) by willy (subscriber, #9762) [Link] Ice cream for everybody!
Merge window opens, kgdb merged Posted Apr 19, 2008 15:20 UTC (Sat) by muwlgr (guest, #35359) [Link] 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 Posted Apr 19, 2008 15:36 UTC (Sat) by rvfh (subscriber, #31018) [Link] 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 Posted Apr 19, 2008 17:12 UTC (Sat) by mingo (subscriber, #31122) [Link] 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 Posted Apr 19, 2008 19:58 UTC (Sat) by rvfh (subscriber, #31018) [Link] 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 :)
Merge window opens, kgdb merged Posted Apr 19, 2008 22:55 UTC (Sat) by adobriyan (guest, #30858) [Link] > Doesn't this mean that the error/kloc figure is a bit biased then?What errors are you talking about? Nastygrams that even checkpatch.pl itself calls "WARNING"s?
kmemcheck and ftrace Posted Apr 19, 2008 18:26 UTC (Sat) by Felix_the_Mac (guest, #32242) [Link] 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 Posted Apr 19, 2008 22:09 UTC (Sat) by joib (guest, #8541) [Link] 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 Posted Apr 19, 2008 22:54 UTC (Sat) by sbergman27 (guest, #10767) [Link] 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 Posted Apr 20, 2008 1:37 UTC (Sun) by rsidd (subscriber, #2582) [Link] 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 Posted Apr 20, 2008 6:23 UTC (Sun) by Cato (subscriber, #7643) [Link] 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 Posted Apr 20, 2008 7:59 UTC (Sun) by trey (subscriber, #37500) [Link] Not a single system image (SSI). Imho runs multiple instances of Linux kernel.
Big shared-memory x86 machines Posted Apr 20, 2008 8:48 UTC (Sun) by joib (guest, #8541) [Link] 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 Posted Apr 22, 2008 12:46 UTC (Tue) by knan (subscriber, #3940) [Link] 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 Posted Apr 19, 2008 22:54 UTC (Sat) by linuxbox (subscriber, #6928) [Link] 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 Posted Apr 20, 2008 20:34 UTC (Sun) by nowster (subscriber, #67) [Link] The latest git updates (post 2.6.25) fix ath5k's symbol problems.
|
|||||||||||||