Re: [Patch 01/12] Prepare the code for Hardware Breakpointinterfaces

[K.Prasad]

On Wed, May 27, 2009 at 01:48:30PM +0200, Frederic Weisbecker wrote:
> On Wed, May 27, 2009 at 02:19:17PM +0530, K.Prasad wrote:
> > On Wed, May 27, 2009 at 03:01:15AM +0200, Frederic Weisbecker wrote:
> > > On Thu, May 21, 2009 at 07:30:33PM +0530, K.Prasad wrote:
> > > > This patch introduces header files containing constants, structure definitions
> > > > and declaration of functions used by the hardware breakpoint interface code.
> > > > 
> > > > Original-patch-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
> > > > Signed-off-by: K.Prasad <prasad@xxxxxxxxxxxxxxxxxx>
> > > > Reviewed-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
> > > > ---
> > > > Index: linux-2.6-tip.hbkpt/arch/x86/include/asm/processor.h
> > > > ===================================================================
> > > > --- linux-2.6-tip.hbkpt.orig/arch/x86/include/asm/processor.h
> > > > +++ linux-2.6-tip.hbkpt/arch/x86/include/asm/processor.h
> > > > @@ -29,6 +29,7 @@ struct mm_struct;
> > > >  #include <linux/threads.h>
> > > >  #include <linux/init.h>
> > > >  
> > > > +#define HBP_NUM 4
> > > >  /*
> > > >   * Default implementation of macro that returns current
> > > >   * instruction pointer ("program counter").
> > > > @@ -433,12 +434,11 @@ struct thread_struct {
> > > >  #endif
> > > >  	unsigned long		gs;
> > > >  	/* Hardware debugging registers: */
> > > > -	unsigned long		debugreg0;
> > > > -	unsigned long		debugreg1;
> > > > -	unsigned long		debugreg2;
> > > > -	unsigned long		debugreg3;
> > > > +	unsigned long		debugreg[HBP_NUM];
> > > 
> > > 
> > > 
> > > Note that each patches must leave a buildable kernel, even
> > > if these patches are contained in a set logic.
> > > 
> > > I haven't tried yet, but I suspect this patch, if applied
> > > without the rest, will cause a build error.
> > > 
> > > There are still some sites that use the removed fields above.
> > > 
> > > A solution would be to temporarily fix these sites in this patch
> > > by using the new debugreg array interface. Even if you remove
> > > some of them in further patches in this series, for example
> > > by using the new load_debug_registers() helper, it will follow
> > > the logic step by step and leave a buildable kernel at each
> > > middle step.
> > > 
> > > That implies to modify also some of the other patches of this
> > > series, but all of these changes should be trivial.
> > > 
> > > Thanks,
> > > 
> > > Frederic.
> > >
> > 
> > The debugreg<n> removal patches were correct, even as recent as
> > http://lkml.org/lkml/2009/5/11/160 and I guess I messed-up meanwhile.
> > Thanks for pointing it out - I've now moved them to Patch 8/12 along
> > with the ptrace changes.
> > 
> > The rest of the patches allow the kernel tree to be compiled though.
> > Would you prefer a new iteration with these changes, or can I send
> > individual patches with the changes discussed above?
> > 
> > Thanks,
> > K.Prasad
> >  
> 
> 
> Yeah you can resend those two individual patches. That's fine.
> Just increase the version number and keep their place (1/12 and 8/12)
> so that I won't run into confusion :)
> 
> Thanks!
>

Hi Frederic,
	Please find the updated Patch 1/12 here:
http://lkml.org/lkml/2009/5/27/345/ and Patch 8/12 here:
http://lkml.org/lkml/2009/5/27/346/.

Without much foresight, I didnot track the changes in the patchset
through version numbering (I'm doing it for the PPC64 patchset atleast),
and wasn't very comfortable to call these new patches as ver II at this
late a stage. Hope that would be acceptable to you!

Thanks,
K.Prasad

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/