Re: [RFC][PATCH] HPET: register additional counter-only char device

[Dimitri Gorokhovik]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/