Re: [PATCH 0/2] utrace

["Frank Ch. Eigler" <fche@redhat.com>]

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