[Crash-utility] PATCH v2 00/10] teach crash to work with "live" ramdump
Dave Anderson
anderson at redhat.com
Mon May 2 15:06:51 UTC 2016
----- Original Message -----
> 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.
I have no problem with LOCAL_ACTIVE() being defined like that.
However, now I'm wondering whether "LIVEDUMP" should be renamed to differentiate it
from LIVE_DUMP. LIVE_DUMP means one of two things:
(1) On an s390x, a dumpfile was take by firmware of a running system.
(2) The snap.so extension module was used to create an ELF vmcore of a running system.
So both are static dumpfiles, but were taken while the system was running live.
In this case, it's more like /dev/mem et al, and it's non-static. Maybe "LIVE_RAMDUMP"?
Dave
>
> 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.
>
>
More information about the Crash-utility
mailing list