Re: updating the RTC automagically

Riley Williams (rhw@MemAlpha.CX)
Fri, 19 Nov 1999 14:21:33 +0000 (GMT)


Hi Ulrich.

>>>>> I investigated what would be needed to set the RTC when the
>>>>> system time changes. First the inverse function for mktime() is
>>>>> needed (i.e. convert UNIX time to days, hours, months, etc.)
>>>>> Then the function to set the RTC would have to be extended to
>>>>> set _all_ the values, not just minute and second.

>>>>> Should I take the date conversion routine from the C library
>>>>> (i.e. copy the code)?

>>>> Are you proposing to put this facility in the kernel? There's
>>>> already a perfectly good userspace program to do that - take a
>>>> peek at `man hwclock` for details.

>>> A real UNIX system can also set the clock.

>> Define "A real UNIX" for me, as you obviously mean something
>> different to what I understand it to be - or, for that matter,
>> what the authors of the various different UNIX clones I've used
>> in my 20 years as a programmer understand it to be.

> In case if you follow comp.protocols.time.ntp occasionally, you
> will find out that a lot of problems are related to problems
> where Linux does not update the RTC properly (e.g. when running
> localtime, not UTC).

I can understand the point you're making, but would have to point out
that Linux is NOT the main culprit here - that 'honour' belongs to a
certain MacroHard range of products.

To be blunt, where a system needs to dual boot between LoseSleep and
*ANY* decent operating system, and LoseSleep is set to honour DST,
then the RTC *MUST* be run in localtime rather than UTC/GMT as if it
isn't, LoseSleep will trash it for you. If you want to get this fixed,
persuade MacroHard to fix it as they're the only ones who can...

> Let's say HP-UX 11.0 is a real UNIX if that helps you.

You still haven't convinved me that Linux is any less of a real UNIX,
and arguments that clearly place the blame in the wrong place (like
your argument above does) are unlikely to do so.

> I'm also aware that the RTC update code is basically unchanged
> since Linux 0.99.

You're probably also aware that the most likely reason for that is
that no change has ever been needed since then.

>>>>> I'm not subscribed here, but I'd like to be CC:'d for
>>>>> replies...

>>>> There are quite a few people don't bother replying to mailing
>>>> list postings that state the poster isn't subscribed to the
>>>> list, on the basis of "if (s)he can't be bother to subscribe,
>>>> I can't be bothered to reply"...

>>> Getting 200 messages per day is not an option if it's not your
>>> fulltime job.

>> {Shrug} It's not my fulltime job, but I quite happily handle the
>> full linux-kernel feed, together with several other mailing lists
>> - my mailbox averages somewhere between 500 and 700 new messages
>> a day.

> Maybe you have a real Internet connection, possibly even at home.
> Different here.

Glancing at my (BT Highway) ISDN-2 connection, I wonder what sort of
connection you have?

>> However, that's beside the point: My comment was simply to
>> explain why the author might not get as many replies as they
>> might expect, and was NOT a criticism of any sort.

>> It happens to be fact that such happens, as is the fact that
>> some people have spam filters that kill any mail containing the
>> word "subscribe" because of the number of such messages that

> s/subscribe/subscribe\[^d\]/ ;-)

Don't tell me, tell them. I don't have any such line in my spam
filter, as should be apparent from the fact that I received your
original email despite it containing the said word...

>> reach the various mailing lists instead of majordomo or listserv
>> or whatever. As a result, such people would not have even seen
>> that message in the first place.

Best wishes from Riley.

PS: The kernel versions page is now back online at the URL below, and
includes separate sublists both for each kernel series, and for
each year of development.

+----------------------------------------------------------------------+
| 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. |
+----------------------------------------------------------------------+
* http://www.memalpha.cx/Linux/Kernel/

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