Re: User-space probes: Plan B+

[fche at redhat dot com (Frank Ch. Eigler)]

Hi -

jamesdi wrote:

> [...]  Probing a function that is called often would be a major
> slowdown, as soon as you fire a probe the entire application stops,
> instrumenting something like malloc creates a huge slow down as your
> process, goes to the kernel, then back userland to run the script,

This speculation contemplates the worst possible implementation
scenarios for user-space probing.  This is not what we have in mind.

> and then back even if the probe wasn't even interested in the
> particular event. [...]

Unlike broad strace/ptrace, the intent is to ensconce and surveil only
interesting probes.

> [...]
> > But I think it's better to provide a feature for which a need has been
> > identified -- even if the feature requires careful use and a few minutes
> > to understand -- than to withhold the feature [...]
>
> its better to design the system with safety and security in
> mind. [...]

Those things are not mutually contradictory.

> [...]  They ended up with a solution that works for the expert
> programmer and overworked system administrator, as well as the
> weekend home user [...]

You are confusing a proposed internal low-level implementation, and
its high-level software client.  Few are imagining having end-users
write raw kprobes, utrace clients, or solaris device drivers for that
matter.


- FChE