On 14-08-08 01:50 PM, Yoshihiro YUNOMAE wrote:Hmm. Probably not.
This patch set introduces new traceevents in order to output
messages. Current SCSI printk messages in upstream kernel can be
divided by and
mixed with other messages. Even if each error message has its
sometimes we can easily be lost in mixed logs because the
message's device id
is separated from it's body. To avoid it, I'd like to use
store error messages into the ftrace or perf buuffer, because
are atomically commited to the buffer.
In this patch set, all printk messages are removed based on a local
discussion with Hannes, but I think printk messages should be kept
users don't enable traceevents and rsyslog can store as files.
However, if printk of logging branch is kept, the messages are
it can induce stack overflow by using local buffer(*1).
So, my suggestion is follows:
Keeps current implemntation of upstream kernel.
The messages are divided and can be mixed, but all users can check
messages without any settings.
To get the complete messages, we can use ftrace or perf (or
something on them).
Users can always understand correct messages, but they need to set
This patch set is based on Hannes' logging branch:
[1/10] ~ [6/10]: just cleanup for logging branch
[7/10] ~ [10/10]: introduce new traceevents
Any comments are welcome!
In sg3_utils there are now string yielding equivalents
to the sense buffer "print" functions. They take a form
char * get_sense_str(const unsigned char * sense_buffer,
int sb_len, int blen, char * b);
So this just does the hard work of decoding the sense buffer
(or saying it is invalid) the result of which it places in
buffer 'b'. And 'b' is returned (so this function can be in
the arguments of a driver's printing function).
Adding such string functions would give other parts of the
SCSI subsystem the capability of tailoring their own
messages that include sense data information.
Existing sense buffer "print" function could be kept and
implemented using the newer "_str" variants. Would that
be worth the trouble?