[Crash-utility] [PATCH] add a new command: ipcs

[qiaonuohan]

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 at cn.fujitsu.com
--------------------------------------------------
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