Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Yao Qi <yao@codesourcery.com>
Cc: <gdb-patches@sourceware.org>
Subject: Re: [PATCH 1/6] new observer command_option_changed.
Date: Tue, 24 Jul 2012 20:39:00 -0000	[thread overview]
Message-ID: <87394gopwj.fsf@fleche.redhat.com> (raw)
In-Reply-To: <1343146252-22558-2-git-send-email-yao@codesourcery.com> (Yao	Qi's message of "Wed, 25 Jul 2012 00:10:47 +0800")

>>>>> "Yao" == Yao Qi <yao@codesourcery.com> writes:

Yao> This patch is to add an extra field 'notify_observer_p' to identify
Yao> the command will notify observer 'command_option_changed', and teach
Yao> GDB to check the change of command option, and notify observer.

I read through the series to find out why this was needed.
My understanding is that the idea is that options will be segregated
into two kinds: those which report via the observer, and others; and
that the decision is made in the gdb sources.

If that is accurate, I wonder if you could explain the rationale for it.
Another possible design would be to report all option changes; or to let
the MI client choose.

The reason I ask is that making the decision statically seems tricky.
When adding an option, what criteria do we use to decide?  How do we
know what MI users want?  Or what if we want to add a Python hook
here -- maybe we would switch many more options over; but does switching
an option from non-reporting to reporting cause issues for existing MI
clients?  (I assume there is at least a bandwidth concern...)

Yao> +const char *auto_boolean_enums[] = { "on", "off", "auto", NULL };

It seems like now this should be 'const char * const'.
I realize you're just moving it, so normally it would be exempt from
this kind of tweakery, but in this case it is also now exported...

Yao> +		if (c->notify_observer_p)
Yao> +		  {
Yao> +		    char *s = (char *) auto_boolean_enums[val];

I don't think the cast is needed.

Yao> +@deftypefun void command_option_changed (const char *@var{command}, const char *@var{option})
Yao> +The option of some @code{set} commands in console are changed.  This method is called after
Yao> +a command @code{set command option}.
Yao> +@end deftypefun

The lines in the body are all too long.

I think it would be good to describe the meaning of the arguments.


What happens in the case where an option has a validation function that
fails?  IIRC gdb has an internal design flaw here.

Tom


  reply	other threads:[~2012-07-24 20:39 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-24 16:11 [RFC 0/6] MI notification of command option change Yao Qi
2012-07-24 16:11 ` [PATCH 6/6] new add_setshow_string_cmd_with_notif and trace-notes Yao Qi
2012-07-24 20:54   ` Tom Tromey
2012-07-24 16:11 ` [PATCH 3/6] attach to command_option-changed observer Yao Qi
2012-07-24 17:10   ` Eli Zaretskii
2012-07-24 20:47   ` Tom Tromey
2012-07-26 12:47     ` Yao Qi
2012-07-26 13:59       ` Tom Tromey
2012-07-26 15:31   ` Pedro Alves
2012-07-24 16:11 ` [PATCH 1/6] new observer command_option_changed Yao Qi
2012-07-24 20:39   ` Tom Tromey [this message]
2012-07-25  3:56     ` Yao Qi
2012-07-25 14:44       ` Tom Tromey
2012-07-26 15:21         ` Pedro Alves
2012-07-25 14:32   ` Tom Tromey
2012-07-26  8:55     ` Yao Qi
2012-07-24 16:11 ` [PATCH 4/6] new add_setshow_enum_cmd_with_notif and scheduler-locking Yao Qi
2012-07-24 20:50   ` Tom Tromey
2012-07-26 15:41     ` Pedro Alves
2012-07-24 16:11 ` [PATCH 2/6] allow to suppress more mi notification Yao Qi
2012-07-24 20:40   ` Tom Tromey
2012-07-26 15:30   ` Pedro Alves
2012-07-27  2:57     ` Yao Qi
2012-07-27 13:27       ` Pedro Alves
2012-07-24 16:12 ` [PATCH 5/6] new add_setshow_boolean_cmd_with_notify and circular-trace-buffer Yao Qi
2012-07-24 20:53   ` Tom Tromey
2012-07-27 15:23 [RCF 0/6 V2] MI notification of command option change Yao Qi
2012-07-27 15:23 ` [PATCH 1/6] new observer command_option_changed Yao Qi
2012-07-27 17:56   ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87394gopwj.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=yao@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox