I suspect that is most often the case. My task, working for an OEM,
is to provide access to the available hardware. The customer's decide
if the hardware is appropriate to their needs, and still many customers
are demanding access to these devices. I am going to try to do a study
on whether additional hardware timers are of any benefit given the
resources available on current standard hardware and the availability of
the high-res patch, but the additional hardware is probably still going
to be available because it is needed on others OS's.
> You MAY want to consider using your hardware as the system clock
> underlying jiffies and all the system timers, but that is
> another issue.
>
> You also may want to define a new CLOCK for the POSIX
> timers. Most of this capability is in place in the current
> patch. I did notice, however, that I took a short cut on
> the clock_nanosleep code and assumed that it was a standard
> clock. This is easy to change... The new CLOCK(s) would
> then talk to your hardware. The problem you will encounter,
> and which the high-res-patch solves, is making the timers
> available to all comers, i.e. there is no reservation system
> or busy counter, etc. Just a nice set timer and give me a
> signal when it is done.
>
Hmmm, that sounds promising.
> You can code a blocking interface using the sigwait and
> friends calls which will also cut down of the timer delivery
> overhead by eliminating the signal.
Very good.
> So what more could you ask for?
I've already sent Santa my list.
Thanks for the advice.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/