Philippe Gerum wrote:
> ...
> Ok, I'm not going to argue about cleanliness or brokenness about this...
> issue, because it's first and foremost a matter of taste. The main
> point, I think, is this one: is the clock device something which may be
> changed on-the-fly during real-time operations, in such a way that we
> would have to atomically switch the device and get its frequency?
> Moreover, would this all-in-one approach guarantee anything when we use
> the frequency value to rescale timeout values, much later, long after
> the atomic section has been exited?
> Because the answer is no, then I would not go for yet another interface
> breaking backward compatibility (even if I agree that we could live with
> a few patches being obsoleted), just for the purpose of getting the
> frequency in some atomic fashion, a guarantee which would not leave
> beyond the return point from ipipe_request_tickdev(), and above all, a
> guarantee we have no actual use of. This is where "cleanliness" may bite
> harder than perceived "brokenness".

Let's wait for my patches, and you may understand what I mean (e.g. that
the timer frequency is delivered by the selected clock_event_device -
atomically or not).


Xenomai-core mailing list

Reply via email to