>>> 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)?
>> Sounds like a bad idea.
> Two people told me it's a bad idea so far.
Memory says Linus decided such was a bad idea many months ago, and
unless you can convince him otherwise, any change you offer will get
nowhere.
>> (i) The function exists already and lives in user space -
>> hwclock.
>> (ii) This would add a very large amount of bloat without any
>> increase in functionality.
> I think it would be a great chance to fix hardware dependent
> things where it is the best place. What can hwclock do that the
> kernel can't?
hwclock can determine the correct timezone based on values read from
the relevant configuration file, these values including the following:
1. What the timezone is called.
2. What the offset from GMT is when DST is not in effect.
3. Whether DST is used in this timezone.
4. The date and time at which DST commences.
5. The date and time at which DST finishes.
6. The offset from non-DST to DST (normally 60 minutes, but both
75 minute and 90 minute offsets occur, and maybe others).
There are probably other values as well, and storing a table of those
in the kernel for all possible timezones is simply unnecessary bloat.
> How can hwclock set the kernel, if the kernel can't.
Are you planning on creating a set of RTC drivers for all the
different RTC chips that get used in various computers?
> Would you implement code for any of the platforms using #ifdef
> or what?
I wouldn't waste my time implementing it at all, as the CORRECT
version already exists.
> (iia) This would add a maintenance duty to update kernel data
> each time some political body takes a decision about when DST
> starts, etc.
> It wouldn't be much different from now. Just imagine if you set
> the time (maybe using settimeofday()), the kernel will the
> timezone it knows about to update the clock.
If you set the time, you decide whether it's a temporary change (to
allow one to test some time-related bug in a program) or a permanent
change. If it's to be a permanent change, you run hwclock after
setting the time; if it's temporary, you don't.
> I don't want to put the DST decision logic into the kernel, just
> the timezone offset.
The two are intimately connected, and you can't have one without the
other.
> The latter is needed by DOSish filesystems anyway.
What the various DOS filesystems need is a mount parameter that says
something like the following...
Q> mount -t vfat -o tz=MST /dev/hda2 /win95
...where the "tz=MST" tells it to treat all on-disk times as being in
the "MST" timezone. Anything else is plain stupidity...
>> I hope you realize that libc uses /etc/localtime which points at
>> some file in /usr/share/zoneinfo or so, and since one cannot
>> access such files from the kernel, they would have to be
>> compiled into the kernel.
> I hope you realize that timezone is basically a number ;-)
See above for proof to the contrary...
>> Even if a configuration option selects the part you need, this
>> would still add more than a megabyte to the kernel source.
> I had a kilobytes or something like that in mind, with the
> possibility to simplyfy some other stuff. Maybe really have a
> look to the current snapshot of PPSkit-0.9.0pre2. You will get a
> feeling what parts are missing...
Considering the standard of your comments so far, I'll forego the
pleasure of wasting my time.
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/