Re: 'info os' additions again

[Pedro Alves <palves@redhat.com>]

On 05/10/2012 10:07 PM, Stan Shebs wrote:

> On 5/10/12 11:58 AM, Pedro Alves wrote:
>> On 05/10/2012 07:42 PM, Stan Shebs wrote:
>>
>>> On 5/10/12 11:18 AM, Pedro Alves wrote:
>>>> On 05/10/2012 07:12 PM, Stan Shebs wrote:
>>>>
>>>>> They're waiting for the GDB bits (including the MI patch which is in my queue) to become available, which is why I want to get this resolved one way or another.  It's a little ironic that Eclipse folks, who don't care about command-line syntax, are being blocked on a discussion of command-line syntax. :-)
>>>>>
>>>>> If everybody is tired of the issue, I'll just make a decision; things can always be changed later.
>>>> What kind of decision?  What would exactly be the alternative?
>>>>
>>> To pick one of "info os" and "info linux".  I don't think there are many other credible alternatives; the subcommand should be a single
>>> short word, with the rest of the work to be done by subsubcommands and/or arguments. "info unix" or "info posix" would qualify, but
>>> historically we've tended to avoid using those terms in GDB commands, and one could argue that they have the
>>> same vagueness/overloading issue that "os" does.
>> Frankly, this reads as a misunderstanding of all whole thing to me.  Just
>> picking out a name in isolation of the grand scheme doesn't make sense.
>>
>> How would "info linux" be implemented?  How would be backend know you're
>> requesting linux specific data?  What would make "info linux" against a
>> Windows target return error or nothing, instead of returning Windows
>> specific tables?  What's the point in making "linux" be in the command
>> name if the frontend is completely agnostic, by design, to what is beneath
>> the command?
>>
>> IOW, renaming the command means implementing something completely different.
>>
> 
> Well yes, of course the implementation would be completely different.  The original objections to the patch were to the user interface, so we need to agree on that first.


For me, the main motivation for the change is to have a mechanism in the frontend
what works to display all these objects for random OSs without having to change
GDB or the frontend.  E.g,. if a Nucleus or other OS stub wants to display
some fancy table, it'll feed it to "-info-os", and things just work.
The GNU/Linux tables that are being exposed by the patch in question are
already easily available to the command line user using other mechanisms (like
e.g., ipcs).  Mostly, the patch is just a layer on top of /proc.  The real value is
in shoving them in structured form.  IOW, to me, the Elipse plugin as is, is the
real value added.
Giving up on that, and replacing it with hard coding "info linux foo",
"info linux bar whatnot" is a step backwards, IMNSHO.

> 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".

-- 
Pedro Alves