Re: Serial maintainership

[David S. Miller]

From: Linus Torvalds <torvalds@xxxxxxxx>
Date: Thu, 8 Sep 2005 09:27:56 -0700 (PDT)

> Mistakes happen, and the way you fix them is not to pull a tantrum, but 
> tell people that they are idiots and they broke something, and get them to 
> fix it instead.

In all this noise I still haven't seen what is wrong with
the build warning fix I made.

Even as networking maintainer, other people put changes into the
networking as build or warning fixes, and I have to live with that.
If I don't like what happened, I call it out and send in a more
appropriate fix.  This is never something worth peeing my pants in
public about.

Anyways, let's discuss the concrete problem here.

The previous definition of uart_handle_sysrq_char(), when
SUPPORT_SYSRQ was disabled, was a plain macro define to "(0)" but this
makes gcc emit empty statement warnings (and rightly so) in cases such
as:

		if (tty == NULL) {
			uart_handle_sysrq_char(&up->port, ch, regs);
			continue;
		}

(that example is from drivers/sun/sunsab.c)

So I changed it so that it was an inline function, borrowing the
existing code, so that we get the warning erased _and_ we get type
checking even when SUPPORT_SYSRQ is disabled.  So we end up with:

static inline int
uart_handle_sysrq_char(struct uart_port *port, unsigned int ch,
		       struct pt_regs *regs)
{
#ifdef SUPPORT_SYSRQ
	if (port->sysrq) {
		if (ch && time_before(jiffies, port->sysrq)) {
			handle_sysrq(ch, regs, NULL);
			port->sysrq = 0;
			return 1;
		}
		port->sysrq = 0;
	}
#endif
	return 0;
}

which is what is there now.  I can't see what's so wrong with that.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/