[...]
> Are you planning on creating a set of RTC drivers for all the
> different RTC chips that get used in various computers?
I thought that should be done in arch/*/kernel/time.c ...
If the kernel doesn't know the RTC you have, hwclock will have
trouble as well I guess.
>
> > 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.
I could resist the temptation to look at the code so far, and I bet
the thing can be significantly improved if I look at it. But for the
time I know enough products and sources...
[...]
> 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.
Think real: How mayn users would do that, and even if they do, what's
wrong setting the time to the correct value after your tests? Still,
I see no problem if the update is optional. Ther framework already
exists.
>
> > 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.
Yes, but you can separate essence from bloat.
>
> > 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
As long as mounts are local, the timezone should be obvious. Why
duplicate the information?
>
> ...where the "tz=MST" tells it to treat all on-disk times as being in
> the "MST" timezone. Anything else is plain stupidity...
That's your opinion.
[...]
> > I hope you realize that timezone is basically a number ;-)
>
> See above for proof to the contrary...
I'm not convinced timezone is not a number.
[...]
> Considering the standard of your comments so far, I'll forego the
> pleasure of wasting my time.
I'm afraid my English is not good enough to comprehend.
Regards,
Ulrich
-
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/