Re: [PATCH] Add schedule_timeout_{interruptible,uninterruptible}{,_msecs}() interfaces

[Nishanth Aravamudan]

On 23.07.2005 [19:17:37 +0200], Roman Zippel wrote:
> Hi,
> 
> On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
> 
> > > Keep the thing as simple as possible and jiffies _are_ simple. Please show 
> > > me the problem, that needs to be fixed.
> > 
> > I am not sure why jiffies are any simpler than milliseconds. In the
> > millisecond case, conversion happens in common code and only needs to be
> > audited once. In the jiffies case, I have to check *every* caller to see
> > if they are doing stupid math :)
> 
> Jiffies are the basic time unit for kernel timers, hiding that fact gives 
> users only wrong expectations about them.

We already have msleep() and msleep_interruptible(), which hide jiffies
in milliseconds. These interfaces are their parallel in the wait-queue
case. If you don't want to use them, or their use is not appropriate,
then the callers won't be changed.

> I don't mind using helper functions, but constant conversion can already 
> happen at compile time and for variable timeouts the user should seriously 
> consider using jiffies directly instead of constantly converting time 
> values.

My goal is to distinguish between these cases in sleeping-logic:

1) tick-oriented
	use schedule_timeout(), add_timer(), etc.

2) time-oriented
	use schedule_timeout_msecs()

I am not going to run some global sed script to change the whole kernel.
I may not always be successful, but I do try to be cautious in my
patches. Only those callers that can benefit from using a millisecond
interface will be changed.

Another question (actually the same question expressed again), do Andrew
or Arjan think I should reinsert the
schedule_timeout_{,un}interruptible() functions for the 1) case above?

Thanks,
Nish
-
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/