[lkml]   [1999]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: i386/RTC: old problem, new solution?
Hi Richard.

>>> The only place I'm aware that the kernel needs to know the
>>> timezone is this case with suspend/resume. So aside from this,
>>> I don't see a need for the kernel to know the timezone.

>> That's really the second place where it would be useful. The first
>> is during the initial boot stages, from kernel loading to the point
>> in the initialisation where `hwclock --hctosys` is run, since during
>> this interval, messages sent to syslogd or klogd get stamped with
>> the RTC time taken as UTC even if it isn't...

> I don't see that. Provided you update the system clock before
> starting syslogd, the times recorded will be correct. The kernel
> ring buffer doesn't store timestamps. It's syslogd that adds the
> timestamps.

So the times appearing in /var/log/messages are the times when syslogd
put its grubby paws on the message then, and not when it was issued?

Maybe I'm being stupid, but it seems to me that having the kernel tag
the timestamp when the message was generated onto the message would
help with tracking down races as it would provide a better idea of
just when various problems occurred...

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:51    [W:0.070 / U:0.572 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site