On Fri, 2005-07-15 at 12:58 -0700, Stephen Pollei wrote: > But If I understand Linus's points he wants jiffies to remain a memory > fetch, and make sure it doesn't turn into a singing dancing christmas > tree.
It seems it relatively easy to support dynamic tick, the ARM architecture has it. But with the numerous users of jiffies through the code, it seems to me that it's hard to ensure that everyone of them will continue to work correctly if the jiffies_increment is changed during runtime. As Linus noted, the current tick code is flexible and powerful, but it can be hard to get it right in all case. WinCE developers have similar problems/concerns: http://blogs.msdn.com/ce_base/archive/2005/06/08/426762.aspx With the previous cleanup like time_after()/time_before(), msleep() and friends, unit conversion helpers, etc. it's a step in the right direction. I just wanted to point out that while it's good to preserve the current efficient tick implementation, it may be worthwhile to add a relative timeout API like Alan Cox proposed a year ago to better hide the implementation details. - Eric St-Laurent - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
