Announce: kdb v1.9 is available for kernel 2.4.16

Announce: kdb v1.9 is available for kernel 2.4.16

[Keith Owens]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Content-Type: text/plain; charset=us-ascii

ftp://oss.sgi.com/projects/kdb/download/ix86/kdb-v1.9-2.4.16.bz2
ftp://oss.sgi.com/projects/kdb/download/ia64/kdb-v1.9-2.4.16-ia64-011128.bz2

Ethan Solomita (ethan@cs.columbia.edu) has done a port of kdb to
sparc64 against 2.4.13.  I will upgrade that to 2.4.16, integrate it
with the other kdb changes since 2.4.13 and release it in a few days.

This will probably be the last release of kdb using this patch format.
I plan to split kdb into a core patch and smaller arch dependent
patches, instead of one big patch for each arch.

Changelog extract.

2001-12-03 Keith Owens  <kaos@sgi.com>

	* Upgrade to 2.4.16.
	* Add include/asm-um/kdb.h stub to allow XFS to be tested under UML.
	* Check if an interrupt frame on i386 came from user space.
	* Out of scope bug fix in kdb_id.c.  Ethan Solomita.
	* Changes to common code to support sparc64.  Ethan Solomita.
	* Change GFP_KERNEL to GFP_ATOMIC in disasm.  Ethan Solomita.

2001-11-16 Keith Owens  <kaos@sgi.com>

	* Upgrade to 2.4.15-pre5.
	* Wrap () around #define expressions with unary operators.

2001-11-13 Keith Owens  <kaos@sgi.com>

	* Upgrade to 2.4.15-pre4.
	* kbdm_pg.c patch from Hugh Dickins.

2001-11-07 Keith Owens  <kaos@sgi.com>

	* Upgrade to 2.4.14-ia64-011105.
	* Change name of l1 serial I/O routine, add ia64 init command.  SGI.
	* Sync kdbm_pg with XFS.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Exmh version 2.1.1 10/15/1999

iD8DBQE8CxeSi4UHNye0ZOoRAg5XAJ0X38pwRAQn626kA52x3blkPqJEZQCfYFZf
uEs8b9QtISbATIBWtO44H/M=
=01s4
-----END PGP SIGNATURE-----

Re: Announce: kdb v1.9 is available for kernel 2.4.16

[Christoph Hellwig]

On Mon, Dec 03, 2001 at 05:11:31PM +1100, Keith Owens wrote:
> This will probably be the last release of kdb using this patch format.
> I plan to split kdb into a core patch and smaller arch dependent
> patches, instead of one big patch for each arch.

Why can't you release one kdb patch instead?

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

Re: Announce: kdb v1.9 is available for kernel 2.4.16

[Keith Owens]

On Mon, 3 Dec 2001 08:43:10 +0100, 
Christoph Hellwig <hch@caldera.de> wrote:
>On Mon, Dec 03, 2001 at 05:11:31PM +1100, Keith Owens wrote:
>> This will probably be the last release of kdb using this patch format.
>> I plan to split kdb into a core patch and smaller arch dependent
>> patches, instead of one big patch for each arch.
>
>Why can't you release one kdb patch instead?

Because every architecture except i386 differes from the base kernel.
IA64 has its own large patch set that has to be applied to the main
kernel before kdb can be applied.  Sparc uses the vger kernel tree.
The -ac trees are different again.

Re: Announce: kdb v1.9 is available for kernel 2.4.16

[Juan Quintela]

>>>>> "keith" == Keith Owens <kaos@melbourne.sgi.com> writes:

keith> On Mon, 3 Dec 2001 08:43:10 +0100, 
keith> Christoph Hellwig <hch@caldera.de> wrote:
>> On Mon, Dec 03, 2001 at 05:11:31PM +1100, Keith Owens wrote:
>>> This will probably be the last release of kdb using this patch format.
>>> I plan to split kdb into a core patch and smaller arch dependent
>>> patches, instead of one big patch for each arch.
>> 
>> Why can't you release one kdb patch instead?

keith> Because every architecture except i386 differes from the base kernel.
keith> IA64 has its own large patch set that has to be applied to the main
keith> kernel before kdb can be applied.  Sparc uses the vger kernel tree.
keith> The -ac trees are different again.

That is bad, now that you are able to create a kernel that will
compile in i386 & ia64 with latest ia64 patch, I will also like to
be able to integrate kdb there with support for both archs.

Later, Juan.


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

Re: [Linux-ia64] Announce: kdb v1.9 is available for kernel 2.4.16

[Hiro Yoshioka]

Keith,

I have a naive question.

Is there any chance to be merged into Linus's linux?

If not, why? If yes, when?

Thanks in advance,
  Hiro

From: Keith Owens <kaos@sgi.com>
Subject: [Linux-ia64] Announce: kdb v1.9 is available for kernel 2.4.16
Date: Mon, 03 Dec 2001 17:11:31 +1100
Message-ID: <3838.1007359891@kao2.melbourne.sgi.com>

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Content-Type: text/plain; charset=us-ascii
> 
> ftp://oss.sgi.com/projects/kdb/download/ix86/kdb-v1.9-2.4.16.bz2
> ftp://oss.sgi.com/projects/kdb/download/ia64/kdb-v1.9-2.4.16-ia64-011128.bz2
> 
> Ethan Solomita (ethan@cs.columbia.edu) has done a port of kdb to
> sparc64 against 2.4.13.  I will upgrade that to 2.4.16, integrate it
> with the other kdb changes since 2.4.13 and release it in a few days.
> 
> This will probably be the last release of kdb using this patch format.
> I plan to split kdb into a core patch and smaller arch dependent
> patches, instead of one big patch for each arch.
> 
> Changelog extract.
> 
> 2001-12-03 Keith Owens  <kaos@sgi.com>
> 
> 	* Upgrade to 2.4.16.
> 	* Add include/asm-um/kdb.h stub to allow XFS to be tested under UML.
> 	* Check if an interrupt frame on i386 came from user space.
> 	* Out of scope bug fix in kdb_id.c.  Ethan Solomita.
> 	* Changes to common code to support sparc64.  Ethan Solomita.
> 	* Change GFP_KERNEL to GFP_ATOMIC in disasm.  Ethan Solomita.
> 
> 2001-11-16 Keith Owens  <kaos@sgi.com>
> 
> 	* Upgrade to 2.4.15-pre5.
> 	* Wrap () around #define expressions with unary operators.
> 
> 2001-11-13 Keith Owens  <kaos@sgi.com>
> 
> 	* Upgrade to 2.4.15-pre4.
> 	* kbdm_pg.c patch from Hugh Dickins.
> 
> 2001-11-07 Keith Owens  <kaos@sgi.com>
> 
> 	* Upgrade to 2.4.14-ia64-011105.
> 	* Change name of l1 serial I/O routine, add ia64 init command.  SGI.
> 	* Sync kdbm_pg with XFS.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: Exmh version 2.1.1 10/15/1999
> 
> iD8DBQE8CxeSi4UHNye0ZOoRAg5XAJ0X38pwRAQn626kA52x3blkPqJEZQCfYFZf
> uEs8b9QtISbATIBWtO44H/M=
> =01s4
> -----END PGP SIGNATURE-----
> 
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64

Re: [Linux-ia64] Announce: kdb v1.9 is available for kernel 2.4.16

[Keith Owens]

On Tue, 04 Dec 2001 10:50:51 +0900, 
Hiro Yoshioka <hyoshiok@miraclelinux.com> wrote:
>I have a naive question.
>Is there any chance (kdb) to be merged into Linus's linux?
>If not, why? If yes, when?

http://www.lib.uaa.alaska.edu/linux-kernel/archive/2000-Week-36/0575.html
http://marc.theaimsgroup.com/?l=linux-kernel&m=96865229622167&w=2

Re: [Linux-ia64] Announce: kdb v1.9 is available for kernel 2.4.16

[David Woodhouse]

kaos@melbourne.sgi.com said:
> http://www.lib.uaa.alaska.edu/linux-kernel/archive/2000-Week-36/0575.html
> http://marc.theaimsgroup.com/?l=linux-kernel&m=96865229622167&w=2 

The answer, of course, is to do all your debugging in the MIPS kernel, which
even in Linus' tree contains gdb stubs, although I think Linus' tree is 
missing the gdbconsole which sends all printk output as GDB $O packets.

	(gdb) tar rem /dev/ttyS0
	Remote debugging using /dev/ttyS0
	0x80110070 in breakinst ()
	(gdb) cont
	Continuing.
	CPU revision is: 00002721
	FPU revision is: 00002720
	Primary instruction cache 16KiB.
	Primary data cache 16KiB.
	Secondary cache 256KiB, linesize 32 bytes.
	Enabling secondary cache...Done
	Tertiary cache present, not (yet) enabled
	TLB has 64 entries.
	Linux version 2.4.16-0.4 (dwmw2@passion.cambridge.redhat.com) (gcc version

While I sort of see Linus' point, there are two cases where it falls down 
most often for me.

Firstly, roughly half the bugs which I track by poking around with GDB are
caused by toolchain/compiler problems, not by bogus code. Looking at the
code and thinking hard does _not_ help you here. You have to see what's
buggered, compare the code with the asm and slowly find out what went wrong.
If BUG() contains a breakpoint and you can poke at it all immediately,
that's a _lot_ easier than forty-five recompilations and reboots with extra
printks in random places, the final one of which changes the compiler's
output so it no longer exhibits the same bug.

Secondly, the point about not having a debugger making you more careful may
be true - but half the time I track bugs, they're not in my own code. In
fact, I'd go as far as to say the 99% of the bugs I actually use GDB for
aren't in my own code. Some _other_ bugger has been careless, and I'm here
trying to pick up the pieces. 

(Sorry for taking the bait - but anything's better than the evolution thread)

--
dwmw2

Re: [Linux-ia64] Announce: kdb v1.9 is available for kernel 2.4.16

[slurn]

> 
> 
> 
> While I sort of see Linus' point, there are two cases where it falls down 
> most often for me.

Actually, I don't see any part of Linus' point.   Kdb is a tool, just as
much as vi or cscope are tools that aid in kernel development.   Anyone
who would throw away a useful tool because he doesn't think it is pretty
(or that a tool should be used at all) is a fool.

The biggest advantage to kdb is its ability to help understand code 
more quickly than just reading it.   The ability to stop at a particular
point and see how you got there can aid in the process of learning the 
source and the multitude of pathways through the code. 

Additionally, one can often repair a defect by modifying a register
and continuing, thus increasing productivity over debug techniques that
include printk() and reboot.

scott

> 
> Firstly, roughly half the bugs which I track by poking around with GDB are
> caused by toolchain/compiler problems, not by bogus code. Looking at the
> code and thinking hard does _not_ help you here. You have to see what's
> buggered, compare the code with the asm and slowly find out what went wrong.
> If BUG() contains a breakpoint and you can poke at it all immediately,
> that's a _lot_ easier than forty-five recompilations and reboots with extra
> printks in random places, the final one of which changes the compiler's
> output so it no longer exhibits the same bug.
> 
> Secondly, the point about not having a debugger making you more careful may
> be true - but half the time I track bugs, they're not in my own code. In
> fact, I'd go as far as to say the 99% of the bugs I actually use GDB for
> aren't in my own code. Some _other_ bugger has been careless, and I'm here
> trying to pick up the pieces. 
> 
> (Sorry for taking the bait - but anything's better than the evolution thread)
> 
> --
> dwmw2
>