lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1177109495.9479.81.camel@piet2.bluelane.com>
Date:	Fri, 20 Apr 2007 15:51:35 -0700
From:	Piet Delaney <pdelaney@...elane.com>
To:	Randy Dunlap <randy.dunlap@...cle.com>,
	Sergei Shtylyov <sshtylyov@...mvista.com>,
	Jason Wessel <jason.wessel@...driver.com>
Cc:	pdelaney@...elane.com, Piet Delaney <piet@...elane.com>,
	Tom Rini <trini@...nel.crashing.org>, Andi Kleen <ak@...e.de>,
	Dave Jiang <djiang@...sta.com>, linux-kernel@...r.kernel.org,
	sshtylyov@...mvista.com, Andrew Morton <akpm@...l.org>,
	George Anzinger <george@...dturkeyranch.net>,
	David O'Brien <obrien@...eBSD.org>
Subject: Re: Permanent Kgdb integration into the kernel - lets get with it.

On Tue, 2007-04-17 at 11:30 -0700, Randy Dunlap wrote:
> On Thu, 08 Mar 2007 14:24:10 -0800 Piet Delaney wrote:
> 
> > On Thu, 2007-03-08 at 11:49 -0700, Tom Rini wrote:
> > > On Thu, Mar 08, 2007 at 07:37:56PM +0100, Andi Kleen wrote:
> > > > On Thursday 08 March 2007 18:44, Dave Jiang wrote:
> > > > 
> > > > > In spite of kgdb, shouldn't it have that \n anyways in case some other code
> > > > > gets added in the future after the macro? Or are you saying that there should
> > > > > never be any code ever after that macro?
> > > > 
> > > > Sure if there is mainline code added after that macro we add the \n.
> > > > But only if it makes sense to add code there, which it didn't in kgdb.
> > > 
> > > Was that because with recent enough tools and config options there was
> > > enough annotations so GDB could finally figure out where things had
> > > stopped?  Thanks.
> > 
> > The reason Linus said he didn't allow George's kgdb mm patch to 
> > be integrating into the kernel a year or two ago was that Amit and
> > George had significantly different implementations. So Amit, Tom, 
> > George, and the rest of the kgdb development gang worked together 
> > and came up with a unified version that we now support on SourceForge. 
> > 
> > Tom rolled up a mm patch back in December for Andrew and then the
> > integration process stopped. I suggest we work together on getting
> > the kgdb patch back into the mm series and permanently into the kernel
> > like the kexec code and then we can avoid this kernel development
> > obfuscation.
> 
> Hi,
> Is there any movement on this?

Hi Randy:

Jason Wessel <jason.wessel@...driver.com> is currently leading yet
another attempt at getting kgdb permanently into the kernel. Jason
has a linux2_6_21 patch on SourceForge:
	
http://kgdb.cvs.sourceforge.net/kgdb/kgdb-2/8250.patch?view=log&pathrev=linux2_6_21_uprev

and has been working with Sergei Shtylyov <sshtylyov@...mvista.com>
recently on getting KGDBOE Netpoll patches that got lost around the 
time of Tom's attempt. Just on Monday there were a dozen posting to 
the source forge mailing list:

	

kgdb-bugreport@...ts.sourceforge.net

on this effort.

I'd like to see a git repository on kernel.org that is used to update
the mainstream kernel. Unfortunately getting accounts on kernel.org is
next to impossible. If Jason doesn't have one yet it would be nice to
offer him one for the kgdb developers to use. 

I agree with Andi that the kgdb code seems to be getting more
complicated that needed thought I don't find the hooks offensive.
Here I keep my kgdb hooks completely under #ifdef KGDB, so there
is absolutely no difference to the kernel when KGDB isn't configured.
I also like having debug printks, similar to the SOCK_DEBUG() macros,
to make it easy to watch kgdb internals in action. Ya can't run kgdb
on itself. 

I find these blemish's a minor concern compared to the damage/lost
of not integrating kgdb into the kernel permanently. When developers
can't rely on using kgdb for easy development they tend to write code
without consideration for what it's like using their code with the
debugger. Linux is making a major headway into $100 embedded systems;
the recent use in the Linksys WRT54GL (DD-WRT) and Engenius EOC-3220
for example. Making kgdb easily accessible will make the viability of
using Linux for embedded system greatly increased, IMHO. 

Perhaps with a bit of support from the kernel.org folks we could get
the kgdb patch, with all of it's blemishes, into Andrews 2.6.21-rc7-mm1
patch. Accounts on kernel.org for kgdb developers would be a modest
effort. I find the CVS patch framework rather clumsy and would rather
follow the KISS principle and just use git repositories like the rest
of the kernel developers appear to be using.

-piet

> 
> Thanks,
> ---
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
-- 
Piet Delaney                                    Phone: (408) 200-5256
Blue Lane Technologies                          Fax:   (408) 200-5299
10450 Bubb Rd.
Cupertino, Ca. 95014                            Email: piet@...elane.com

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ