Messages in this thread | | | Date | Fri, 29 Aug 2008 15:04:41 -0400 | From | "Frank Ch. Eigler" <> | 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
| |