Re: [Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump
On 04/26, Dave Anderson wrote:
> and that is what this part of changelog
>
> The usage of CRASHBUILTIN doesn't look nice, we need to cleanup
> this logic. I hope we can do this later, and it seems to me that
> the usage of MEMORY_SOURCES/DUMPFILE_TYPES needs some cleanups in
> any case.
>
> in 9/10 tried to say ;)
CRASHBUILTIN is used to indicate the the Red Hat /dev/crash driver exists and
the kernel module was built into the kernel -- as opposed to having to load the
crash.ko driver. I'm not sure how that is associated with this facility.
Yes, yes, I see how it is used now. Damn, but now I also see that my changelog
looks very confusing!
"The usage of CRASHBUILTIN doesn't look nice" above means "The usage of
CRASHBUILTIN
IN THIS PATCH doesn't look nice", and I even added the FIXME comment. Sorry for
confusion Dave.
> Say, memory_page_size(). It does "switch (pc->flags
& MEMORY_SOURCES)" and it
> needs the update if we move (say) NETDUMP in pc->flags2. Trivial, but needs
> another patch/discussion/etc.
Who said to move NETDUMP? I only suggested the REM_NETDUMP (and the other REM_xxx)
dumpfiles.
Ah, yes.
> So, if REMOTE() is false, fd_init() calls
get_live_memory_source() if
> pc->dumpfile is NULL. This is not what RAMDUMP need, so 09/10 has to initialize
> pc->dumpfile. At the same time memory_source_init() assumes that if
> pc->dumpfile must at least exist if it is non-NULL. Perhaps this needs needs
> some cleanups too, but this is off-topic right now.
Right, presumably there would need to be a separate "if (QEMU_ACTIVE())"
section
in memory_source_init().
Well, I still disagree, see the previous email... I still think we need some
generic macro.
> Heh ;). and I think fd_init() is simply wrong. The problem is
minor and off-topic
> too, I'll report it later (probably with simple fixes tomorrow). But in short,
> you can't use /dev/crash unless you are root, and if you root and /dev/crash
> is modular then /dev/crash will be removed and the module will be unloaded when
> the crash exits, even if it was not loaded/created by crash. Although I need
> to verify this, I can be wrong.
Correct. When it's modular (and it isn't any more), the module is unloaded and
/dev/crash is purposely removed. It works as intended.
Even if this module was loaded and /dev/crash existed before I start /bin/crash?
# ll /dev/crash
cr--r--r--. 1 root root 10, 57 Apr 26 12:33 /dev/crash
# crash ../VMLINUX
...
WARNING: ../VMLINUX and /proc/version do not match!
(just in case, this is correct)
# ll /dev/crash
ls: cannot access /dev/crash: No such file or directory
doesn't look friendly.
And I can't use /bin/crash without root even if I do "chmod a+r /dev/crash"
on my
machine.
Is it all intentional?
Oleg.