[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080829190441.GM2888@redhat.com>
Date: Fri, 29 Aug 2008 15:04:41 -0400
From: "Frank Ch. Eigler" <fche@...hat.com>
To: Alexey Dobriyan <adobriyan@...il.com>
Cc: Roland McGrath <roland@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] utrace
Hi -
> > As for whether "struct utrace" should be a member of vs. pointed-to
> > from task_struct, it may come down to the perceived need to avoid
> > penalizing every thread with a hundred-odd bytes extra, whether or not
> > they are being utrace-controlled.
>
> Yes, that's your price for avoiding more races, more code, more races,
> more tricky code and ultimately more ways to fsckup. [...]
> When you're confident that interaction with engines part is fine, all
> stupid bugs were fixed, go change struct utrace to pointer. [...]
That's an idea worth considering, especially given the oopses you
found (thanks!).
> [...]
> > [...] All this code now exists in at
> > least prototype form, so if you need to see the bigger picture, look
> > that way. Other users are anticipated, but first we need to get past
> > the chicken-and-egg.
>
> There are no chickens and no eggs.
>
> utrace is in RHEL4, RHEL5, FC6, FC7, FC8, FC9 kernels already.
> I can't believe RedHat allowed to totally rewrite ptrace based on some
> prototype code.
Well, that was how red hat broke the deadlock, and why RH kernels will
probably get working user-space systemtap probing earliest.
> > > This all similar to systemtap/markers story. Big changes under
> > > promises that now, now somebody will use our thing.
> >
> > In what way do you think those promises are unfulfilled? Systemtap
> > has interfaced to markers since the beginning,
> It just wants entry point, right?
(I don't understand what you mean. If you mean "does systemtap just
want function entry points a la ftrace", then the answer is no, it
needs (& already has) more than that.)
> > and there are a bunch of markers in the tree.
> Total 3 in scheduler and in spufs (ppc-specific).
Some of those hits represent more via macros, but anyway, more on
their way (kmemcheck, lttng).
> Amazing improvement for ugly macros, more self-modified kernel,
> explicit reasons stated why they are stupid spelt in review and
> after entering tree, and general dislike of some maintainers to add
> more trace_mark() entries.
Regardless of the strength of technical objections/responses, there is
an ingrained cultural aspect to this that perhaps we'll break through
at the summit.
> So there were promises that markers will be useful, 10 months passed
> and they are still useless. [...]
They are already useful to their users.
- FChE
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists