Messages in this thread | | | Date | Wed, 27 May 2009 13:48:30 +0200 | From | Frederic Weisbecker <> | Subject | Re: [Patch 01/12] Prepare the code for Hardware Breakpoint interfaces |
| |
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@rowland.harvard.edu> > > > Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com> > > > Reviewed-by: Alan Stern <stern@rowland.harvard.edu> > > > --- > > > 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!
| |