Subject: RE: printk_ratelimit and net_ratelimit conflict and tunable
	behavior
From: Joe Perches <joe@perches.com>
To: Hawkes Steve-FSH016 <Steve.Hawkes@motorola.com>
Cc: David Miller <davem@davemloft.net>, LKML <linux-kernel@vger.kernel.org>
In-Reply-To: <7BFDACCD6948EF4D8FE8F4888A91596A016371FE@tx14exm60.ds.mot.com>
References: <7BFDACCD6948EF4D8FE8F4888A91596A016371E8@tx14exm60.ds.mot.com>
	 <20080220.223219.165157596.davem@davemloft.net>
	 <1203577246.7181.241.camel@localhost>
	 <7BFDACCD6948EF4D8FE8F4888A91596A016371FA@tx14exm60.ds.mot.com>
	 <1203970417.19319.287.camel@localhost>
	 <7BFDACCD6948EF4D8FE8F4888A91596A016371FE@tx14exm60.ds.mot.com>
Content-Type: text/plain
Date: Mon, 25 Feb 2008 16:04:38 -0800
Message-Id: <1203984278.19319.312.camel@localhost>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 858
Lines: 23

On Mon, 2008-02-25 at 17:49 -0600, Hawkes Steve-FSH016 wrote:
> Are you saying the few lines of code to handle changes to the tunables
> aren't worth keeping?

Yes.

I think the tunables, if needed at all, should be set by modifying
the struct and the call might as well be:
	
bool __printk_ratelimit(struct printk_ratelimit_state *state)

Another quibble is not directed to your change because it's
preexisting but "tok" isn't a good name and may not even need
to be in the structure.  It does save a multiply though.

I think that anything that attempts a printk is slow path
so it doesn't matter much though.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/