Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758941AbZCURc5 (ORCPT ); Sat, 21 Mar 2009 13:32:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754786AbZCURcr (ORCPT ); Sat, 21 Mar 2009 13:32:47 -0400 Received: from e23smtp09.au.ibm.com ([202.81.31.142]:41656 "EHLO e23smtp09.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754495AbZCURcr (ORCPT ); Sat, 21 Mar 2009 13:32:47 -0400 Date: Sat, 21 Mar 2009 23:02:32 +0530 From: "K.Prasad" To: Ingo Molnar Cc: Alan Stern , Linux Kernel Mailing List , Andrew Morton , Benjamin Herrenschmidt , Frederic Weisbecker , Maneesh Soni , Roland McGrath , Steven Rostedt Subject: Re: [Patch 01/11] Introducing generic hardware breakpoint handler interfaces Message-ID: <20090321173232.GC9906@in.ibm.com> Reply-To: prasad@linux.vnet.ibm.com References: <20090319234804.GB10517@in.ibm.com> <20090320183058.GB31629@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090320183058.GB31629@elte.hu> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1727 Lines: 43 On Fri, Mar 20, 2009 at 07:30:58PM +0100, Ingo Molnar wrote: > > * Alan Stern wrote: > > > > + * Kernel breakpoints grow downwards, starting from HB_NUM > > > + * 'hbkpt_kernel_pos' denotes lowest numbered breakpoint register occupied for > > > + * kernel-space request > > > + */ > > > +unsigned int hbkpt_kernel_pos; > > > > This doesn't make much sense. All you need to know is which > > registers are in use; all others are available. > > > > For example, suppose the kernel allocated breakpoints 3, 2, and 1, > > and then deallocated 2. Then bp 2 would be available for use, > > even though 2 > 1. > > it's a high/low watermark mechanism. Yes, it's not an allocator that > can allocate into a debug registrs 'hole', but it is a simple one > that matches current hardware breakpoint usages and enables the > kernel to utilize them as well - and keeps all the code simple. > > Ingo I've explained the design here: http://lkml.org/lkml/2009/3/21/169 in a and is slightly different from what you've explained above. It involves shifting of kernel-space registers by one-level if a kernel-register is uninstalled. We compact the kernel-space registers since a)not to leave a 'hole' thereby wasting a register forever during runtime b)kernel-space requests are not specific to a register number and can be moved at will (unlike user-space requests). Hope that the design is acceptable and the resultant code - simple. Thanks, K.Prasad -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/