Messages in this thread |  | | | Date | Fri, 19 Nov 1999 14:21:33 +0000 (GMT) | | From | Riley Williams <> | | Subject | Re: updating the RTC automagically |
| |
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/
|  |