Re: engine interaction, callback order

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


> > Would there still be a report_quiesce callback?  Would utrace call
> > report_quiesce when entering quiescence and report_resume when leaving
> > quiescence?

Sorry, I didn't answer this part.  To be decided.  Something like that.
Perhaps report_quiesce should go away entirely.  One idea is leaving it
only for the other cases when not about to resume.  Then report_resume
would be called when first arriving at "almost back to user mode", with its
"action" giving UTRACE_ACTION_QUIESCE if the flag is set.  If the
UTRACE_ACTION_QUIESCE state flag is still set after those callbacks, then
we go into quiescence (TASK_TRACED).  When all engines have cleared
QUIESCE, we wake up, and run report_resume again with UTRACE_ACTION_RESUME
(or with any pending signal ready to be delivered).  Or perhaps it's
clearer to leave report_quiesce, have only that run before stopping while
quiescent, and then run report_resume after waking.  (A report_resume
callback can always decide to set QUIESCE again.)  The benefit of the first
idea is that then report_quiesce (if kept at all) means only the "you can
stop, but I'm not near user mode" cases.  If you want to e.g. look at the
user mode registers in their proper form, you need to wait for
report_resume.  So then if you get report_quiesce before report_resume, it
means there may be a delay before the opportunity to get at the registers
freely (e.g. it may be safe to read but not write them at report_quiesce).


[Index of Archives]     [Kernel Discussion]     [Gimp]     [Yosemite News]

  Powered by Linux