>> Take the messsages generated during booting: If your point is
>> correct, then all messages generated prior to syslogd/klogd
>> starting up are marked with effectively the same timestamp
>> (namely the moment when syslogd reads them), no matter how long
>> apart they really were, and as a result, any races that would've
>> shown up with the true timestamps are of necessity hidden and
>> can only be guessed at...
> Bear in mind that syslogd only keeps timestamps to second
> resolution. That isn't really useful for debugging races. Even
> microsecond resolution can be insufficient for debugging races
> (these days there are a lot of cycles per microsecond). Printing
> timestamps with microsecond or better resolution would just get
> incredibly message.
So what you're saying is that it would be useful for the kernel
routine that produces the syslog messages to insert an extra message
if it gets asked to produce two separate messages less than (say)
250 nanoseconds apart? It certainly shouldn't produce such a message
if it gets asked to produce a multi-line message though.
> I don't think the timestamps help much.
Not as they currently stand, no, but if they're done correctly, then
races should show up easier...
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/