Re: [Crash-utility] PATCH 00/10] teach crash to work with "live" ramdump
On 04/26, Dave Anderson wrote:
> Ah. Yes, the usage of CRASHBUILTIN is ugly, and I tried to document this.
>
> We need the new (say) RAW_MEM_DUMP flag. We can't use RAMDUMP because it can
> be set along with KDUMP.
>
> And there is no room in pc->flags, so I decided to abuse CRASHBUILTIN for now.
I understand.
It's exceeding rare that a new dumpfile type, or a new live system accessor in
this case, gets introduced. When that happens, we can move deprecated leftovers
from pc->flags to pc->flags2. So for example, all of these can be moved to
pc->flags2 in one fell swoop:
REM_NETDUMP
REM_MCLXCD
REM_LKCD
REM_S390D
Yes, yes, sure. But while this is trivial, this needs some tiresome changes.
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 ;)
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.
Another problem is that there is no simple/clear way to tell fd_init() paths that
we do not need get_live_memory_source/memory_source_init. Unless we set
REMOTE() == T but we should not do this.
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.
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.
Oleg.