Messages in this thread | | | Subject | Re: [RFC PATCH 1/2] Marker probes in futex.c | From | Nicholas Miell <> | Date | Tue, 22 Apr 2008 10:50:00 -0700 |
| |
On Sat, 2008-04-19 at 14:48 -0400, Frank Ch. Eigler wrote: > Hi - > > On Sat, Apr 19, 2008 at 08:29:27PM +0200, Peter Zijlstra wrote: > > [...] > > > OTOH I think this is a false dichotomy. Debugging is not only done by > > > a subsystem maintainer during the merge/rc period. When something > > > goes wrong on a deployed machine, problem diagnosis requires data, > > > which ideally should be gathered as non-intrusively as possible - that > > > means no recompiling / rebooting, and ideally very little slowdown. > > > [...] > > > This again tries into the argument about not making markers depend on > > the code structure or implementation details. > > It should not *unnecessarily* depend on those. > > > I'm really wanting to avoid ever having to be obstructed by a marker. So > > any marker that does not represent a solid high level event (to take > > Mathieu's example: a context switch is a context switch, and we'll > > always have one) I'm not comfortable with merging that upstream. > > It is your prerogative as a subsystem maintainer to make a guess about > this. Others may make their own decisions differently, considering > the small costs and potential benefits. > > > So even though these ad-hoc markers might have some diagnostic value > > - I'll never support merging them. If a customer might have some > > issue I can hand him a custom kernel with these markers added in - I > > see absolutely no reason to burden upstream with these. > > Perhaps the kinds of bugs in your code, coupled with the kinds of > customers who experience those bugs, make tolerable this means of > diagnosis (requiring a reboot of their machines into a custom > debugging kernel). The customers I have dealt with (and frankly, I > too) need to diagnose problems on a live running system as much as > possible. They don't run every kernel du jour, so they don't need the > purely hypothetical tools that are dependent on a permanent set of > markers. >
Sun solved this problem for DTrace by applying their stability attributes to all probe points -- i.e. the probes that represent an ABI are marked as such and the temporary debugging probes are marked as unstable.
-- Nicholas Miell <nmiell@comcast.net>
| |