Messages in this thread | | | Subject | Re: [RFC][PATCH] HPET: register additional counter-only char device | From | Dimitri Gorokhovik <> | Date | Sun, 13 Apr 2008 16:40:53 +0200 |
| |
On Fri, 2008-04-11 at 17:57 +0200, Clemens Ladisch wrote: > Dimitri Gorokhovik wrote: > > > > -- to me, /dev/hpet is primarily a timer, not just a counter. It seems > > wrong to me if it, once opened, would mostly fail to its primary > > function (but this of course is all subjective matter). > > There are at least as many available timers as before the change -- a > program that tries to use a timer will still get a timer, and now this > will succeed even if there are other programs that use only the counter. > > Even now, for most programs using /dev/hpet, it actually is just a > counter.
The problem with the implementation of this approach is the multiple hw instrances of HPET, which is currently supported. Unless one can rip it all off and hardwire '/dev/hpet' to a single HPET hardware block (can one ?), I can't seem to figure out how to implement the proposed modification.
An example:
-- an application opens '/dev/hpet'. There are several HPET hw blocks in the system -- physical address of some of them is used -- success is returned. A hw timer slot is not allocated at this point.
-- the app 'mmap's the opened device (the phys address selected in the 'open' is used).
-- some time later, the app issues an 'ioctl' call -- it wants the interrupt enabled and so a hw timer slot has to be allocated.
It appears that there are no timers available on the hw block whose phys addr has been used for open/mmap, but there are free timers on the other(s) HPET hw blocks.
Our choice: a) 'ioctl' should fail; b) 'ioctl' may return a timer from another hw block.
I think b) is fundamentally broken. a) risks to return too many failures with timer slots still available, unless some strategy is devised for distribution of 'open's across the hw blocks.
Now imagine HPET hw blocks are not created equal in the system (most likely, clocking frequency is different). What would be such a strategy in this case ?
All this yields a complex implementation without a real reason (many (most?) systems with only one HPET hw block), and still a problematic user interface (how does one chooses the HPET block he or she wants?), only in the name of the compatibility with the existing interface.
The clean interface would be to have:
/dev/hpet0/counter /timer0 /timer1 /timer2 /...
[/dev/hpet1/...]
'counter' device allowing 'mmap' and 'ioctl(HPET_INFO)', and timer devices allowing rest of IOCTLs and other fops except mmap. Choosing a suitable HPET hw is a policy belonging in the app -- right now it is in the kernel, even thought it is as simple as walking a list.
But then again, such implementation would break the existing interface.
Regards,
Dimitri
-- 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/
| |