On Mon, 2008-04-28 at 11:36 -0700, Andrew Morton wrote:
quoted text
> On Sat, 26 Apr 2008 21:38:54 +0200 Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> 
> > On Thu, 2008-04-24 at 11:03 -0400, Mathieu Desnoyers wrote:
> > > Hi Ingo,
> > > 
> > > Here is a rather large patchset applying kernel instrumentation to
> > > sched-devel.git. It includes, mainly :
> > 
> > I saw this land in sched-devel, how about this:
> > 
> > ---
> > Subject: sched: de-uglyfy marker impact
> > 
> > These trace_mark() things look like someone puked all over the code,
> 
> lol.

Glad to lighten your day a little ;-)

quoted text
> > lets hide the ugly bits.
> 
> It hides the cosmetically-ugly bits, but not the deeply ugly: each of these
> trace points is an extension to the kernel->userspace API, with all that
> this implies.

Agreed, and I'm rather concerned about that as well. OTOH its very
unlikely we'll ever have a Linux that will not have a context switch, or
task wakeup operation.

So tracing these and things like syscall seem safe enough to do -
although I wish it wouldn't look so ugly. 

As for some of these other trace points in this set, dubious.

We can of course clearly state that any marker is free of API
constraints and users will have to cope with them changing. But I'm not
sure that's a realistic position.

quoted text
> > +static inline
> > +void trace_kernel_sched_wakeup(struct rq *rq, struct task_struct *p)
> 
> When doing this please put the newline immediately preceding the function
> name.  Putting it between the `inline' and the return-type-declaration is
> weird.

Sure. Just to clarify my rationale, I like to keep the return type on
the same line when possible so you get a complete picture - the static
and inline qualifiers seem less important, but I don't particularly
care.



--
unsubscribe notice
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/