linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Riley Williams <rhw@MemAlpha.cx>
To: Pavel Machek <pavel@suse.cz>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: PROBLEM: Linux updates RTC secretly when clock synchronizes
Date: Wed, 7 Nov 2001 00:00:39 +0000 (GMT)	[thread overview]
Message-ID: <Pine.LNX.4.21.0111062347080.16087-100000@Consulate.UFP.CX> (raw)
In-Reply-To: <20011106111723.C26034@atrey.karlin.mff.cuni.cz>

Hi Pavel.

>>> That seems as very wrong solution.
>>>
>>> What about just making kernel only _read_ system clock, and
>>> never set it? That looks way cleaner to me.

>> It is cleaner. However, I feel that the RTC code should printk (at
>> least as KERN_DEBUG if not as KERN_NOTICE) whenever the RTC is
>> written to. It's too important a subsystem to be left hidden like
>> it currently is.

> This can be as well done in userland, enforced by whoever does rtc
> writes, no?

If some idiot writes a hwclock replacement that doesn't do logging, and
sets the rtc to the output from /dev/random, how does the kernel enforce
that it must log this to /var/log/messages other than by doing the
printk() itself?

> I propose kernel not to do any writes, so it is only userland left.
> And having printk() in kernel or syslog() in hwclock seems pretty
> much equivalent, with later prefered as it magically works on older
> kernels.

I think we're talking at cross-purposes here, so here's my proposal,
which I feel is the only one that actually makes sense:

 1. The /dev/rtc driver in the kernel is the ONLY code that can
    actually read or write to the RTC registers.

    Alternatively, this could be replaced with a sysctl() if that
    is preferred. The important thing is that there is only ONE way
    of performing this write.

 2. The kernel makes no internal reference to the /dev/rtc driver,
    and it is left to userland tools to sync to the RTC on boot,
    and at other times as required.

 3. Whenever the /dev/rtc driver writes to ANY of the RTC registers
    (whether to set the time, the alarm, or anything else), it logs
    this fact using printk at level KERN_DEBUG. The SYSLOG utility
    can be configured to ignore KERN_DEBUG messages, or to deal with
    them in any other way desired.

If I've demangling your comments correctly, then you've basically said
the same as I've said above. If not, can you please advise how you feel
this proposal should be altered.

Best wishes from Riley.


  reply	other threads:[~2001-11-07  0:02 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-31  0:33 PROBLEM: Linux updates RTC secretly when clock synchronizes Ian Maclaine-cross
2001-10-31  1:05 ` Kurt Roeckx
2001-10-31  2:55   ` Ian Maclaine-cross
2001-10-31 11:52     ` Kurt Roeckx
2001-11-01  0:52       ` Riley Williams
2001-11-01  1:26         ` Kurt Roeckx
2001-11-01 13:57         ` Alex Bligh - linux-kernel
2001-11-02  9:50           ` Riley Williams
2001-11-03 11:41             ` Alex Bligh - linux-kernel
2001-11-03 18:35               ` Riley Williams
2001-11-03 19:19                 ` Alex Bligh - linux-kernel
2001-11-03 21:04                 ` Kurt Roeckx
2001-11-06 10:01                 ` Pavel Machek
2001-11-06  9:57             ` Pavel Machek
2001-11-02 12:16 ` Pavel Machek
2001-11-05 23:08   ` Riley Williams
2001-11-06 10:17     ` Pavel Machek
2001-11-07  0:00       ` Riley Williams [this message]
2001-11-07  0:44         ` Alex Bligh - linux-kernel
2001-11-07  1:01           ` Kurt Roeckx
2001-11-07  1:15             ` Alex Bligh - linux-kernel
2001-11-07  9:24             ` Russell King
2001-11-08 12:26         ` Pavel Machek
2001-11-08 23:00           ` Riley Williams
2001-11-09  9:32             ` Pavel Machek
2001-11-09 21:11               ` Riley Williams
2001-11-09 21:30                 ` Pavel Machek
2001-11-09 22:54                   ` Riley Williams
2001-11-09 23:10                     ` Mark Zealey
2001-11-10 20:04                     ` Pavel Machek
2001-11-10 20:35                       ` Riley Williams
2001-11-10 20:43                         ` Pavel Machek
2001-11-10 20:49                         ` Doug McNaught
2001-11-06  0:20   ` Ian Maclaine-cross
2001-11-06 10:18     ` Pavel Machek
2001-11-08  5:09       ` Ian Maclaine-cross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.21.0111062347080.16087-100000@Consulate.UFP.CX \
    --to=rhw@memalpha.cx \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).