On Wed, Oct 22, 2008 at 04:05:01PM -0200, Glauber Costa wrote: > On Wed, Oct 22, 2008 at 3:54 PM, Eduardo Habkost <[EMAIL PROTECTED]> wrote: > > On Wed, Oct 22, 2008 at 03:42:27PM -0200, Glauber Costa wrote: > >> On Wed, Oct 22, 2008 at 3:35 PM, Eduardo Habkost <[EMAIL PROTECTED]> wrote: > >> > If kvmtrace crashes or gets killed while collecting trace data, stale > >> > trace setup information may be enabled on the kernel, and currently > >> > there is no way to force the previous trace setup to be overwritten > >> > or disabled. > >> > > >> > The following two patches against kvm-userspace will add a new > >> > command-line option to kvmtrace (-f), that will allow the user to > >> > forcibly > >> > clean up an existing trace setup before enabling trace. > >> > >> Why can't we simply disable potential stale setups everytime, before we > >> start? > >> The option would then not be needed > > > > Another kvmtrace instance may be already running. Do we want to kill > > its tracing setup without asking, by default? > do we allow more than one instance?
No. That's why the current behaviour is to fail when there is another instance running. > > Note that if the answer is "yes", we also have the problem in which we > have two or three instances in flight. > Which one of them does the command kill ? Currently, the behaviour of ioctl(KVM_TRACE_DISABLE) when another kvmtrace instance is still running will be: - the previous instance will be still running, but getting no data - the new instance will fail when trying to enable tracing (because the old instance is keeping the old debugfs files open) IMO, aborting by default (and making the user aware that something is wrong if he needs to use -f) looks better than breaking both instances. -- Eduardo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
