From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1820 invoked by alias); 12 May 2012 01:33:24 -0000 Received: (qmail 1812 invoked by uid 22791); 12 May 2012 01:33:23 -0000 X-SWARE-Spam-Status: No, hits=-5.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-lpp01m010-f41.google.com (HELO mail-lpp01m010-f41.google.com) (209.85.215.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 12 May 2012 01:33:10 +0000 Received: by lahi5 with SMTP id i5so2802433lah.0 for ; Fri, 11 May 2012 18:33:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.48.73 with SMTP id j9mr89981lbn.52.1336786389095; Fri, 11 May 2012 18:33:09 -0700 (PDT) Received: by 10.112.84.197 with HTTP; Fri, 11 May 2012 18:33:09 -0700 (PDT) In-Reply-To: <4FAD551F.4020506@redhat.com> References: <4FA9A2FA.3090307@earthlink.net> <83k40m0xqt.fsf@gnu.org> <4FAADEBE.7010908@earthlink.net> <83pqaczk9u.fsf@gnu.org> <4FABB2DC.6030905@redhat.com> <4FAC051C.1090208@earthlink.net> <4FAC065C.4030901@redhat.com> <4FAC0C15.8070009@earthlink.net> <4FAC0FD2.4080307@redhat.com> <4FAC2DF8.9020209@earthlink.net> <4FAD551F.4020506@redhat.com> Date: Sat, 12 May 2012 01:33:00 -0000 Message-ID: Subject: Re: 'info os' additions again From: Matt Rice To: Pedro Alves Cc: Stan Shebs , gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg00464.txt.bz2 On Fri, May 11, 2012 at 11:06 AM, Pedro Alves wrote: > On 05/10/2012 10:07 PM, Stan Shebs wrote: >> In practice, an "info linux" would be installed as a target-specific com= mand a la "info spu" > >> and the like, and may or may not pass through generic table machinery be= fore getting >> down to the linux-specific types. =A0It would probably be messier than t= he >> current design I think, but not excessively so. > > As I said, we should not assume anything about the tables "info os" retur= ns. > If not using "info os" then it's best to either use a completely > different mechanism, or we need to define standard tables, and put them > in a namespace, like we do with xml target features. > > But then again, if not going the "info os" style, we could also > consider making "info proc" list the info, or even consider each > table/object individually -- it might make sense to put different objects > at different FOOs in "info FOO OBJECT", or even in the top level, > like "info WHATEVEROBJECT". FWIW i'm entirely swayed by Pedro's argument for 'info os', I'd been considering porting to one of the eros/capros/coyotos family of OS's at some point the existing (kernel) debugger has a lot of this style of tabular data: http://www.capros.org/devel/CrossGuide/kdb-ref.html between refining terms, and replacing ideas the word used to identify the things of a given purpose has been known to change between the OS's though much has stayed the same, while this is a non-existent port and should be weighed as such, info os seems to me the best fit proposed, I'd hate to have a heirarchy for each with much in common under different 'info FOOs', or inversely try to make do with a single heirarchy for the entire family under a more specific name with changing contents, thus at least in this specific sub case the genericness of the 'info os' name, makes the varying of its contents somewhat tolerable.