'info os' additions again

[Stan Shebs <stanshebs at earthlink dot net>]

Back in December and January, we had some spirited discussion of how to 
handle additions to 'info os', triggered by 
http://sourceware.org/ml/gdb-patches/2011-12/msg00829.html , which adds 
a bunch of useful info types for Linux.  Anyway, upon rereading the 
thread, I'm not at all clear on where there was consensus, and if so, 
what the consensus was.

From what I gather, nobody has much of a problem with GDB gathering and 
presenting the info; by passing it through GDB, we can replace raw 
numbers with symbols, get it into history, add to breakpoint command 
lists, etc.

The main sticking point seems to be syntax.

I tend to favor "info os <type> <subtype>..." because it fits the 
progressive refinement that is a hallmark of GDB commands - the user can 
remember it as "info, and it's OS-related, but I just want semaphores".  
The user doesn't have to consider what OS name might be expected, "os" 
always works to connect to the class of OS-specific info displays.

However, we also have an alternate tradition of "info <target> 
<type>...", including "info dos", "info w32", "info spu", etc.  By that 
tradition, Linux-specific info should be "info linux", and if there were 
BSD OS info, it would be "info bsd", and so forth.  It's simpler to 
document, because the manual can just have a section for each subcommand 
that enumerates the subsubcommands that are available.  Unfortunately 
for consistency, we've also had "info os" for several years.

So there are several questions at hand:

1. What to do with the submitted patch?  ("info os" or "info linux" or 
something else)

2. What policy to set for the future?

3. Change existing info commands to conform to a policy, or allow 
inconsistencies for the sake of backward compatibility?

Stan