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). Jan _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
