Hmm. I thought that you were already agree on MEMSRC_LOCAL usage.
On 05/02, Dave Anderson wrote:
>
> > > @@ -124,6 +124,7 @@ fd_init(void)
> > >
> > > if (!pc->dumpfile) {
> > > pc->flags |= LIVE_SYSTEM;
> > > + pc->flags2 |= MEMSRC_LOCAL;
> > > get_live_memory_source();
> > > }
> > >
> > > Now that MEMSRC_LOCAL has been effectively moved out of the way,
> > > why is it being set above in fd_init()?
> >
> > Hmm. But where else? I do not mind to change, but fd_init() looks like a
> > most natural place to me. In any case it should be already set before
> > fd_init() checks LOCAL_ACTIVE() (changed by the next patch) before
> > match_proc_version(), 11 lines below in the same branch.
>
> MEMSRC_LOCAL has always only been set in remote_fd_init() to signal that, for
> whatever reason, the memory source is local but the vmlinux is remote.
Yes I see,
> But
> remoted_fd_init() would only be called if the deprecated remote crash daemon
> was actually running on another machine and a command line argument specified it.
Yes so the usage of MEMSRC_LOCAL here and in LOCAL_ACTIVE() can not conflict with
the old remote code.
> So for all practical purposes MEMSRC_LOCAL is an unused no-op, and should not
> be set above.
So how should I define LOCAL_ACTIVE() ? As for this patchset I can equally do
#define LOCAL_ACTIVE() ((pc->flags & (LIVE_SYSTEM|LIVEDUMP)) == LIVE_SYSTEM)
I do not like this because I still think that LOCAL_ACTIVE doesn't need to
know about LIVEDUMP added by this series, but I won't argue.
Or I still do not understand you?
And just in case, it is not that I like the fact this patchset abuses MEMSRC_LOCAL,
but (as I thought we have already discussed) it will be very simple to change this
later: ignoring the deprecated remote code paths, only fd_init() and LOCAL_ACTIVE()
use this flag directly.
So what do you want me to do instead?
Oleg.
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
