Hello Dave,
I am going to fix the bug on some kernels. And I also need to confirm
the style with you.
At 2012-4-11 4:00, Dave Anderson wrote:
I should note that I*only* tested the "ipcs" command entered alone.
Anyway, I now see that you separated the shared memory display into two
options, -m and -M. I don't believe that is necessary -- the first patch that
you posted gave enough basic information. If you want to expand it, perhaps the
extra data that is shown by "-M" option could be included in the "-i id" output?
And for that matter, the -u data could also be contained in the "-i id" output?
That way the basic shared memory data could be shown by "ipcs [-m]" option, and
a fully-exploded display could be done by the "-i id" qualifier because it
wouldn't have to be restricted to one line.
I separate the display in two places beacuse displaying all items
violates the 80-column rule. And the "-m" shows like the command
system's build-in command. Actually, the reason why I change it like
this is because the inode is important to my proposer. He wants to use
it to identify memory area from such inode information. As you said, the
information displayed by "-M" can be contained in the "-i id" output.
But we have to get the address of inode one by one. I think debugger
will prefer getting data at one time.
I also wish you had followed my original suggestion and made this into an extension
module first. If you do that, you could just post a single "ipcs.c" command that
could be dropped into the "extensions" subdirectory, and built with "make extensions".
There has not been a new command added to the crash utility in many years, and
it's going to be difficult to accept this as a built-in command until it first
goes through a lot of testing, usage, improvement, etc. If it were an extension
module, it could be stored on the extensions web page immediately for people
to use and test.
From the aspect of myself, I would agree with it. But my proposer wants
to use it as soon as possible as a build-in command. I am not sure how
long it will take to convert an extension command to a build-in command.
So I insisted sending it as a build-in command.
Also, if you are not going to support the earlier 2.6-era kernels, then
the command_not_supported() function would be preferable to option_not_supported().
--
--
Regards
Qiao Nuohan
--------------------------------------------------
Qiao Nuohan
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
No. 6 Wenzhu Road, Nanjing, Nanjing, 210012, China
TEL: +86+25-86630566-8526 FUJITSU
INTERNAL: 7998-8526 FAX: +86+25-83317685
EMail: qiaonuohan@xxxxxxxxxxxxxx
--------------------------------------------------
This communication is for use by the intended
recipient(s) only and may contain information that
is privileged, confidential and exempt from
disclosure under applicable law. If you are not an
intended recipient of this communication, you are
hereby notified that any dissemination,
distribution or copying hereof is strictly
prohibited. If you have received this communication
in error, please notify me by reply e-mail,
permanently delete this communication from your
system, and destroy any hard copies you may have
printed
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
