[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Updating MiNT and XaAES (foundations of free, modern Atari system operation)



Hi Sven Karlsson,

SK>>> > Last year I posted here a diff archive for POSIX time (esp. TZ rules)
SK>>> > in mintlib, to patch libsrc PL46.
SK>>Just send diffs (relative to FreeMiNT 1.14beta) and I will inlude them into
SK>>1.14 and release 1.14 pl 2.
I'm using freeMiNT 1.12.6 :-)
And - currently - with no patches (like Tgettimeofday etc.) cause the
TZ-problem i.e. ignoring the POSIX TZ rules, is a matter of libc and not one of
the OS. So the important patches are to mintlib PL46.

I tried to run a patched MiNT including a Tgettimeofday() call:
Just two global variables unixtime_secs and unixtime_msecs, updated during
the 200Hz interrupt
	unixtime_msecs += 5 	value may change with adjtime call
	if unixtime_msecs >= 1000 {
		unixtime_secs += 1
		unixtime_msecs -= 1000 }
which are returned with this call. (I'm not quite sure wether I used a
milli seconds or micro seconds variable, but doesn't matter anyway.)
I initialzed the unixtime_secs variable with the registers of the MegaST
hardware clock - not quite covering every hardware MiNT is running on :-).
And there are other problems: unixtime_secs and Tgettime()/global DOStime
variable soon differ; waste of time to keep two time variables up-to-date
(yes the filesystems - just another problem);
waste of time to adjust the GEMDOS time with the hardware clock - could be
done by a time-daemon with a Tadjtime() function.
This all should be discussed and fixed (why shouldn't we change the filesystems
time stamps to unixtime seconds, ...) before releasing a MiNT with new time
functions, makeing it slower and more complex instead of faster, more simple
and smaller.

So - in daily practice - I'm satisfied with the patches in mintlib I posted
here last year, and the new patch of mintlib's time.c, that would be portable
immediately if everyone agrees to the CLOCK cookie I suggested.

I recommend to run the kernel and the clock in UTC time, and I don't think
the kernel (nor the filesystems) needs to know anything about local time or
time zones or daylight saving.

--
  jerry
        jerry@merlin.abacus.de          jerry@zedat.fu-berlin.de