From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20005 invoked by alias); 8 May 2012 22:49:45 -0000 Received: (qmail 19994 invoked by uid 22791); 8 May 2012 22:49:44 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from elasmtp-galgo.atl.sa.earthlink.net (HELO elasmtp-galgo.atl.sa.earthlink.net) (209.86.89.61) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 May 2012 22:49:32 +0000 Received: from [68.96.200.16] (helo=macbook2.local) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SRtDn-0005CR-0A for gdb-patches@sourceware.org; Tue, 08 May 2012 18:49:31 -0400 Message-ID: <4FA9A2FA.3090307@earthlink.net> Date: Tue, 08 May 2012 22:49:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: 'info os' additions again Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da94085522e29002106475d925bfa0869f4f0350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-05/txt/msg00245.txt.bz2 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 ..." 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 ...", 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