lkml.org 
[lkml]   [2008]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 0/2] utrace
From
Date

Alexey Dobriyan <adobriyan@gmail.com> writes:

> [...] And some internal details still horrible and overdesigned
> just like at the very beginning.

Please point out specific areas, and I'm sure there will be a reasonable
explanation why they turned out this way.

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.


> [...] Linked list of attached tracers? I don't know. One the bad
> side, where are those nice tracing modules? Where are they?

Among others, utrace is an enablement layer for systemtap user-space
probing, through another subsequent part that implements a
kprobes-like API for user-space tasks. 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.


> 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, and there are a bunch
of markers in the tree.


- FChE


\
 
 \ /
  Last update: 2008-08-27 02:29    [W:0.225 / U:0.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site