Hi
tor, 16,.03.2006 kl. 18.40 +0100, skrev Sylvain Petreolle:
> Hi Nils,
> You added uint64_t pit_gettime in the module,
> consequently all modules using it should be including dr-env.h.
>
> (modules/include/fd32/dr-env/stdint.h defines uint*_t)
>
> IMHO we should add dr-env.h into pit.h.
> Is that ok for you ?
I don't have any strong opinion on this, but I don't quite see the need.
Modules would typically include dr-env.h (or maybe a future app-env.h)
explicitly anyway, which just means more work for the preprocessor. But
if you think it is important...
Does anyone else have any opinion?
ons, 15,.03.2006 kl. 16.49 +0800, skrev Hanzac Chen:
> > OK, if we are to have two or more timer modules loaded
> simultaneously,
> > then we need something like the device interface to allow the
> modules to
> > communicate and prevent conflicts. But I don't agree that we should
> rely
> > exclusively on a request function, at least not by default for the
> > generic part of the interface. For example, say I were writing a
> module
> > or application that didn't use a timer module for anything else than
> > nano_delay, then I would want the simplicity of dynamic linking
> rather
> > than the overhead of the device interface. (We could also have a
> command
> > line option to not export anything to the syscall table.)
> Yes, you're right, maybe we should still use the dynamic linking
> (implicitly?).
>
Yes, maybe for part of the interface, with the possibility to configure
it.
> Do you mean that implementing a timer interface to register `timer0',
> `timer1', ... etc. Then can we know which one is PIT timer and which
> one is HPET timer?
>
We could have a TIMER_INFO request that returns data on the timer. If we
want portability, then we need uniformity in the interface. I suppose
these questions will become clearer once we actually have other timer
modules.
Nils
|