On Jan 12, 2008, at 4:29 PM, Bryan Cantrill wrote:
>
>>> I think there's a misunderstanding here about how ustack() works.
>>
>> There's perhaps some of that (and as I pointed out, I would really
>> like to be educated more on this subject)
>
> I'm not sure that you actually do want to be more educated; several
> people
> are trying to educate you here, and it doesn't seem to be taking...
I'm sorry if I wasted your time. It wasn't my intent. Now, since
this will be,
perhaps, the last email between us I just hope you do realize that
starting an answer with the sentence like that significantly devalues
your
subsequent arguments. Why bother writing the rest if the point of the
reply is to flame?
>> Again, for the tool we are building relying on signal trickery is
>> not ideal, but
>> we can survive. If, however, this approach of "transferring" control
>> back and forth
>> between userspace and kernel can be generalized -- I think everybody
>> would
>> benefit from such a mechanism.
>
> Again, this just isn't the way the world works -- when you are deep
> in the context of the kernel, you cannot simply revector control to
> user-land for arbitrary execution.
I don't think you followed my example (the actual D code). If you
did you would have seen that I specifically picked a kernel level
probe (syscall::read) to illustrate how our crude but useful mechanism
works. Nobody is suggesting immediately revectoring the control
flow. As in my example a signal doesn't get delivered immediately.
However it is guaranteed to be delivered before the process in question
gets any chance to chug forward. I agree with the points you made later
in your email, that instrumenting delicate places deep inside the kernel
can not rely on such vectoring of the control flow. I agree with that.
The same way these places can not rely on, lets say system(..)
destructive action. Yet I can use system(...) in such a handler,
can't I?
And even with all the restrictions (and yes I do know about them)
it happens to be quite useful at times. As I pointed out in my email
to Adam -- I was merely trying to suggest a mechanism that would
complement stack() and ustack().
>>
>> Ok, let me try to be extra clear: what I need is a mechanism for
>> passing the control flow back and forth between the kernel executing
>> the action statements and a particular userspace process in the
>> system.
>
> You're asking for the operating system equivalent of a perpetual
> motion
> machine.
Analogies cut both ways. You of all people should know that. Trying
to invent a perpetual motion machine is, perhaps unwise. Talking about
it and carrying out though experiments proved to be quite beneficial to
physics.
> It's not a "potentially good idea", but rather a traditional
> debugger-centric
> notion that reflects a fundamental misunderstanding of the constraints
> of DTrace. Which is not to say that one couldn't implement a
> system around
> these notions, but rather that such a system would be so different
> as to
> longer be DTrace. Indeed, it its features and limitations, it
> would look
> much more like a conventional, process-oriented debugger -- which
> should be
> no surprise given your background and bias...
Sorry. For a minute there I forgot that DTrace was perfect. And it
is just
silly me trying to do stupid things (like zeroing out struct elements
or even
strings) and asking questions that don't even deserve an answer. Sorry.
It won't happen again.
Thanks,
Roman.
_______________________________________________
dtrace-discuss mailing list
[email protected]
