[lkml]   [2001]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: PROBLEM: Linux updates RTC secretly when clock synchronizes
Hi Pavel.

>> If any user can do that, then Linux is borken solid.

> Only root can do that.


>> Just out of curiosity, what is wrong with the idea of having the
>> kernel at iopl(0), any kernel modules at either iopl(1) or iopl(2)
>> and apps at iopl(3) ??? There is obviously something, but I've no
>> idea what.

> It ... just is not that way. Kernel + modules run at ring 0,
> userland at ring 3.

I know that much. I was just curious whether there was any particular
reason why it was that way.

Somebody suggested that it was because of "scheduling hooplas" causing a
serious loss of performance if modules were moved to ring 1. I've no
idea whether such is the case

>>> No. Aim is to leave /dev/rtc in kernel, but make kernel never write
>>> to RTC at its own will.

>> I've no problem with that at all, but the bulk of the comments I've
>> seen in this thread have been very clear about taking /dev/rtc out
>> of the kernel and into a userspace daemon, with the kernel just
>> providing access to the relevant ports to the first app to claim
>> them.

> I do not think so.
> The person who tries to kill /dev/rtc from kernel is going to have
> some problems with me.

They've been getting problems from me - I just checked, and the main
suggestion appears to be to replace /dev/rtc with a sysctl call. I can't
see the point in that myself, and /dev/rtc makes far more sense to me.

I will add that I personally see no problem with the kernel reading RTC
on boot to set the syste clock, although some of the correspondents
appear to have problems with that idea as well.

Best wishes from Riley.

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

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