Re: 'info os' additions again

[Matt Rice <ratmice@gmail.com>]

On Fri, May 11, 2012 at 11:06 AM, Pedro Alves <palves@redhat.com> wrote:
> On 05/10/2012 10:07 PM, Stan Shebs wrote:

>> In practice, an "info linux" would be installed as a target-specific command a la "info spu"
>
>> and the like, and may or may not pass through generic table machinery before getting
>> down to the linux-specific types.  It would probably be messier than the
>> current design I think, but not excessively so.
>
> As I said, we should not assume anything about the tables "info os" returns.
> 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.