| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The timecounter struct is large and I think it may change in the
future. Changing it later will be easier if we use C99-style
initialization for all timecounter structs. It also makes reading the
code a bit easier.
For reasons I cannot explain, switching to C99-style initialization
sometimes changes the hash of the resulting object file, even though
the resulting struct should be the same. So there is a binary change
here, but only sometimes. No behavior should change in either case.
I can't compile-test this everywhere but I have been staring at the
diff for days now and I'm relatively confident this will not break
compilation. Fingers crossed.
ok gnezdo@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This diff exposes parts of clock_gettime(2) and gettimeofday(2) to
userland via libc eliberating processes from the need for a context
switch everytime they want to count the passage of time.
If a timecounter clock can be exposed to userland than it needs to set
its tc_user member to a non-zero value. Tested with one or multiple
counters per architecture.
The timing data is shared through a pointer found in the new ELF
auxiliary vector AUX_openbsd_timekeep containing timehands information
that is frequently updated by the kernel.
Timing differences between the last kernel update and the current time
are adjusted in userland by the tc_get_timecount() function inside the
MD usertc.c file.
This permits a much more responsive environment, quite visible in
browsers, office programs and gaming (apparently one is are able to fly
in Minecraft now).
Tested by robert@, sthen@, naddy@, kmos@, phessler@, and many others!
OK from at least kettenis@, cheloha@, naddy@, sthen@
|
|
|
|
|
|
|
|
| |
amd64/arm64/armv7/i386/sparc64 and move it to the end of machdep.c. Rework the
actual implementation for the MC14818 compatible RTC into something that can
be used as a todr_handle just like on amd64.
ok mpi@
|
|
|
|
| |
ok dlg@ mpi@ deraadt@
|
|
|
|
|
|
|
|
|
|
| |
resetting the clock when we don't need to. Found out with booting hppa64
kernels, and the problem also exists on hppa when booting with '-a' and hitting
'exit' when asked for the root filesystem.
help & ok jsing@
also ok kettenis@ (who suggested naming the variable like amd64/i386 to
prevent creating yet another variant of this code)
|
|
|
|
| |
ok jsing@ kettenis@
|
|
|
|
|
|
| |
other ports (e.g. hppa64) do.
ok jsing@ kettenis@
|
| |
|
|
|
|
| |
ok kettenis@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
already been hit by the running timer; this happens very often on oosiop-based
machines, due to these machines being among the slowest hppa, and oosiop
being interrupt greedy. Unfortunately, when this happened, one had to wait
for the timer to wrap, which would take up to 128 seconds on the 33MHz
machines.
Also, invoke hardclock() as many times as necessary if it turns out that
we had to delay the interrupt 1/hz seconds to avoid the aforementioned
wrap problem.
With help from kettenis@; ok kettenis@
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
(Look ma, I might have broken the tree)
|
| |
|
|
|
|
|
|
|
| |
right thing would be to pass beat count as an argument to timeout
routine (casted to (void *)) avoiding static counter, but
doing timeout_set() every timeout_add() sounds kinda uncool.
well, pondering in the struct timeout guts would be even more ugly.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|