Date: Tue, 09 Apr 2002 22:28:57 -0700
From: "Martin J. Bligh" <Martin.Bligh@us.ibm.com>
Reply-To: "Martin J. Bligh" <Martin.Bligh@us.ibm.com>
To: Andrea Arcangeli <andrea@suse.de>
cc: Andrew Morton <akpm@zip.com.au>, linux-kernel@vger.kernel.org,
        Tony.P.Lee@nokia.com, kessler@us.ibm.com, alan@lxorguk.ukuu.org.uk,
        Dave Jones <davej@suse.de>
Subject: Re: Event logging vs enhancing printk
Message-ID: <2032894297.1018391336@[10.10.2.3]>
In-Reply-To: <20020410032328.C6875@dualathlon.random>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: linux-kernel-owner@vger.kernel.org

>> Right - what I'm proposing would be a generic equivalent of the
>> local staging buffer and sprintf - basically just a little wrapper
>> that does this for you, keeping a per task buffer somewhere.
> 
> That still doesn't solve the race with the interrupt handlers, you'd
> need a buffer for each irq handler and one the softirq too to make
> printk buffered and coeherent coherent across newlines (doable but even
> more tricky and in turn less robust and less self contained).

I was envisaging a larger buffer where the current location pointer 
simply taken by the interrupt handler, and the remaining section of
that buffer was used for the "inner printk". Which is really just 
like a stack, so it makes more sense to just allocate this off the
stack really .... I think this would work? We might need to flush
on a certain size limit (128 chars, maybe?) to stop any risk of
stack overflow.

> Some other code may omit it by mistake, leading to the other cpus
> blackholed and data lost after the buffer on the other cpus overflowed
> so at least we should put a timer that spawns an huge warning if a cpu
> doesn't flush the buffer in a rasonable amount of time so we can catch
> those places.

It seems that 99.9% of these cases are just assembling a line of output 
a few characters at a time. There might be a few odd miscreants around,
but not enough to worry about - I think it's overkill to do the runtime
timer check, but we could always run like this to test it, or try to
work some sort of automated code inspection (though that sounds hard to
do 100% reliably).

M.

-
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/