Re: [patch 2.6.26] /dev/hpet - fixes and cleanup

[David Brownell]

On Wednesday 23 July 2008, Clemens Ladisch wrote:
> David Brownell wrote:
> >   * Tighten and correct the userspace interface code
> >       ...
> >       + only open comparators that have an interrupt, and can thus
> >         perform "real work"
> 
> This prevents userspace applications from doing mmap() on /dev/hpet
> even if there is no interrupt.

OK, I removed that ... HPET_IE_ON will already fail.

I didn't find any software using /dev/hpet, except for
the example in Documentation/hpet.txt ... presumably I
was looking in the wrong place.  I'd surely have retched
at anything mmapping hardware registers though.  ;)


> This seems to be the only part of the userspace interface that is
> used in practice.  Because of the availability of POSIX timers, it might
> make sense to deprecate the HPET ioctl interface.

I'll leave that part up to someone else.  If POSIX timers
are a sufficient userspace interface, great ... then that
mmap son't really be needed either!  In fact, would the
/dev/hpet support even be needed?  It's not very portable...

 
> > And re that kernel interface:  IMO, worth having a relatively
> > generic interface for hardware timers instead of inventing a new
> > interface for each new bit of hardware.
> 
> AFAIK it was intended to be similar to the RTC callback interface, but
> that was before the generic high-precision timer stuff was introduced.

People seem to want access to the hardware backed timers too, and
not necessarily coupled to a task like the RTC stuff assumes.  Folk
who want to drive that issue will need to sort out requirements...
the requests I've heard seem to focus on talking to kernel code.

But since HPET "timers" are really weak compared to what most embedded
platforms offer, I'm quite sure any API designed to its capabilities
would be underfeatured!  Example, there are no external inputs (like
clocks or event pulses) or outputs (PWM or whatever) with HPET, and
likewise no flexibility about inputs (which internal clock, or maybe
external clocks).

- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/