Re: [rfc/remote] Tell remote stubs which signals are boring

[Daniel Jacobowitz <drow@false.org>]

On Thu, Oct 26, 2006 at 11:01:18AM -0400, Eli Zaretskii wrote:
> > On Thu, Oct 26, 2006 at 02:57:29AM -0400, Eli Zaretskii wrote:
> > > > Date: Wed, 25 Oct 2006 17:24:41 -0400
> > > > From: Daniel Jacobowitz <drow@false.org>
> > > > 
> > > > This is the solution I came up with for that problem, adjusted to HEAD
> > > > and given a more sensible packet name.  I have a tested implementation
> > > > of this patch for HEAD, if my remote protocol choices are acceptable.
> > > > The new mechanism is completely transparent to the user.
> > > 
> > > I'm confused: shouldn't this packet be automatically sent to a remote
> > > target when I say, e.g., "handle SIGALRM nostop noprint pass"?  Am I
> > > missing something?
> > 
> > Now I'm confused :-)  Isn't that exactly what I said above?  It's
> > completely transparent; it just works.
> 
> Perhaps I'm too dumb today, but ``completely transparent'' does not
> tell me that there's any connection between `handle' and `set remote
> pass-signals', especially since an interactive command can hardly be
> described as ``transparent to the user''.

It's transparent because you should never, ever have to use "set
remote pass-signals".  If the target reports that it supports
QPassSignals, it will be used automatically.  If it doesn't report it,
then forcing it on isn't going to work, unless the remote target is
buggy (supports the packet but claims not to).  Disabling it is,
again, not useful unless the remote target is buggy (supports the
packet but mishandles it).

This is one of the reasons I mentioned in another message yesterday
that I was thinking of removing or moving to "maint" the various "set
remote" packet controls - they're confusing.  Best would probably be to
both move and rename them: "set remote pass-signals-packet" would
become "maint set remote QPassSignals", with a clear correspondence to
the packet it controls.  It's a design feature of the remote protocol
that everything is autonegotiated, so (just as currently), these would
all default to an "auto" setting.

WDYT?

-- 
Daniel Jacobowitz
CodeSourcery