Hi,
On Wed, 27 Jul 2005, Nishanth Aravamudan wrote:
> > > 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()
> >
> > There is _no_
Hi,
On Wed, 27 Jul 2005, Nishanth Aravamudan wrote:
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()
There is _no_ difference, the scheduler is
On 23.07.2005 [22:12:30 +0200], Roman Zippel wrote:
> Hi,
>
> On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
>
> > > Jiffies are the basic time unit for kernel timers, hiding that fact gives
> > > users only wrong expectations about them.
> >
> > We already have msleep() and
On 23.07.2005 [22:12:30 +0200], Roman Zippel wrote:
Hi,
On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
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
Hi,
On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
> > What's wrong with just:
> >
> >
> > schedule_timeout_{,un}interruptible(msecs_to_jiffies(some_constant_msecs));
>
> Nothing, I suppose. I just prefer directly using msecs. I understand
> your point more now, I think. You are worried
Hi,
On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
> > 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
On 23.07.2005 [19:01:57 +0200], Roman Zippel wrote:
> Hi,
>
> On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
>
> > set_current_state(TASK_{,UN}INTERRUPTIBLE);
> > schedule_timeout(msecs_to_jiffies(some_constant_msecs));
> >
> > just have an interface that allows
> >
> >
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
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
Hi,
On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
> set_current_state(TASK_{,UN}INTERRUPTIBLE);
> schedule_timeout(msecs_to_jiffies(some_constant_msecs));
>
> just have an interface that allows
>
> schedule_timeout_msecs_{,un}interruptible(some_constant_msecs);
>
> and
On 23.07.2005 [15:29:42 +0200], Roman Zippel wrote:
> Hi,
>
> On Sat, 23 Jul 2005, Arjan van de Ven wrote:
>
> > jiffies/HZ is the more powerful API. The msec one which also sets
> > current to (un)interruptible is the simplified wrapper on top.
>
> So why do you want to hide it? Make the
On 23.07.2005 [15:04:44 +0200], Roman Zippel wrote:
> Hi,
>
> On Sat, 23 Jul 2005, Arjan van de Ven wrote:
>
> > > > > What's wrong with using jiffies?
> > > >
> > > > A lot of the (driver) users want a wallclock based timeout. For that,
> > > > miliseconds is a more obvious API with less
On 23.07.2005 [13:55:58 +0200], Roman Zippel wrote:
> Hi,
>
> On Sat, 23 Jul 2005, Arjan van de Ven wrote:
>
> > > What's wrong with using jiffies?
> >
> > A lot of the (driver) users want a wallclock based timeout. For that,
> > miliseconds is a more obvious API with less chance to get the
On 23.07.2005 [12:50:45 +0200], Roman Zippel wrote:
> Hi,
>
> On Fri, 22 Jul 2005, Arjan van de Ven wrote:
>
> > Also I'd rather not add the non-msec ones... either you're raw and use
> > HZ, or you are "cooked" and use the msec variant.. I dont' see the point
> > of adding an "in the middle"
Hi,
On Sat, 23 Jul 2005, Arjan van de Ven wrote:
> > > jiffies/HZ is the more powerful API. The msec one which also sets
> > > current to (un)interruptible is the simplified wrapper on top.
> >
> > So why do you want to hide it?
>
> I don't want to hide it at all. I want to provide a simpler
On Sat, 2005-07-23 at 15:29 +0200, Roman Zippel wrote:
> Hi,
>
> On Sat, 23 Jul 2005, Arjan van de Ven wrote:
>
> > jiffies/HZ is the more powerful API. The msec one which also sets
> > current to (un)interruptible is the simplified wrapper on top.
>
> So why do you want to hide it?
I don't
Hi,
On Sat, 23 Jul 2005, Arjan van de Ven wrote:
> jiffies/HZ is the more powerful API. The msec one which also sets
> current to (un)interruptible is the simplified wrapper on top.
So why do you want to hide it? Make the jiffies based API the primary one
and add some convenience functions,
On Sat, 2005-07-23 at 15:04 +0200, Roman Zippel wrote:
> Hi,
>
> On Sat, 23 Jul 2005, Arjan van de Ven wrote:
>
> > > > > What's wrong with using jiffies?
> > > >
> > > > A lot of the (driver) users want a wallclock based timeout. For that,
> > > > miliseconds is a more obvious API with less
Hi,
On Sat, 23 Jul 2005, Arjan van de Ven wrote:
> > > > What's wrong with using jiffies?
> > >
> > > A lot of the (driver) users want a wallclock based timeout. For that,
> > > miliseconds is a more obvious API with less chance to get the jiffies/HZ
> > > conversion wrong by the driver
On Sat, 2005-07-23 at 13:55 +0200, Roman Zippel wrote:
> Hi,
>
> On Sat, 23 Jul 2005, Arjan van de Ven wrote:
>
> > > What's wrong with using jiffies?
> >
> > A lot of the (driver) users want a wallclock based timeout. For that,
> > miliseconds is a more obvious API with less chance to get the
Hi,
On Sat, 23 Jul 2005, Arjan van de Ven wrote:
> > What's wrong with using jiffies?
>
> A lot of the (driver) users want a wallclock based timeout. For that,
> miliseconds is a more obvious API with less chance to get the jiffies/HZ
> conversion wrong by the driver writer.
We have helper
On Sat, 2005-07-23 at 12:50 +0200, Roman Zippel wrote:
> Hi,
>
> On Fri, 22 Jul 2005, Arjan van de Ven wrote:
>
> > Also I'd rather not add the non-msec ones... either you're raw and use
> > HZ, or you are "cooked" and use the msec variant.. I dont' see the point
> > of adding an "in the middle"
Hi,
On Fri, 22 Jul 2005, Arjan van de Ven wrote:
> Also I'd rather not add the non-msec ones... either you're raw and use
> HZ, or you are "cooked" and use the msec variant.. I dont' see the point
> of adding an "in the middle" one. (Yes this means that several users
> need to be transformed to
Hi,
On Fri, 22 Jul 2005, Arjan van de Ven wrote:
Also I'd rather not add the non-msec ones... either you're raw and use
HZ, or you are cooked and use the msec variant.. I dont' see the point
of adding an in the middle one. (Yes this means that several users
need to be transformed to msecs
On Sat, 2005-07-23 at 12:50 +0200, Roman Zippel wrote:
Hi,
On Fri, 22 Jul 2005, Arjan van de Ven wrote:
Also I'd rather not add the non-msec ones... either you're raw and use
HZ, or you are cooked and use the msec variant.. I dont' see the point
of adding an in the middle one. (Yes
Hi,
On Sat, 23 Jul 2005, Arjan van de Ven wrote:
What's wrong with using jiffies?
A lot of the (driver) users want a wallclock based timeout. For that,
miliseconds is a more obvious API with less chance to get the jiffies/HZ
conversion wrong by the driver writer.
We have helper
On Sat, 2005-07-23 at 13:55 +0200, Roman Zippel wrote:
Hi,
On Sat, 23 Jul 2005, Arjan van de Ven wrote:
What's wrong with using jiffies?
A lot of the (driver) users want a wallclock based timeout. For that,
miliseconds is a more obvious API with less chance to get the jiffies/HZ
Hi,
On Sat, 23 Jul 2005, Arjan van de Ven wrote:
What's wrong with using jiffies?
A lot of the (driver) users want a wallclock based timeout. For that,
miliseconds is a more obvious API with less chance to get the jiffies/HZ
conversion wrong by the driver writer.
We have
On Sat, 2005-07-23 at 15:04 +0200, Roman Zippel wrote:
Hi,
On Sat, 23 Jul 2005, Arjan van de Ven wrote:
What's wrong with using jiffies?
A lot of the (driver) users want a wallclock based timeout. For that,
miliseconds is a more obvious API with less chance to get the
Hi,
On Sat, 23 Jul 2005, Arjan van de Ven wrote:
jiffies/HZ is the more powerful API. The msec one which also sets
current to (un)interruptible is the simplified wrapper on top.
So why do you want to hide it? Make the jiffies based API the primary one
and add some convenience functions,
On Sat, 2005-07-23 at 15:29 +0200, Roman Zippel wrote:
Hi,
On Sat, 23 Jul 2005, Arjan van de Ven wrote:
jiffies/HZ is the more powerful API. The msec one which also sets
current to (un)interruptible is the simplified wrapper on top.
So why do you want to hide it?
I don't want to
Hi,
On Sat, 23 Jul 2005, Arjan van de Ven wrote:
jiffies/HZ is the more powerful API. The msec one which also sets
current to (un)interruptible is the simplified wrapper on top.
So why do you want to hide it?
I don't want to hide it at all. I want to provide a simpler variant for
On 23.07.2005 [12:50:45 +0200], Roman Zippel wrote:
Hi,
On Fri, 22 Jul 2005, Arjan van de Ven wrote:
Also I'd rather not add the non-msec ones... either you're raw and use
HZ, or you are cooked and use the msec variant.. I dont' see the point
of adding an in the middle one. (Yes this
On 23.07.2005 [13:55:58 +0200], Roman Zippel wrote:
Hi,
On Sat, 23 Jul 2005, Arjan van de Ven wrote:
What's wrong with using jiffies?
A lot of the (driver) users want a wallclock based timeout. For that,
miliseconds is a more obvious API with less chance to get the jiffies/HZ
On 23.07.2005 [15:04:44 +0200], Roman Zippel wrote:
Hi,
On Sat, 23 Jul 2005, Arjan van de Ven wrote:
What's wrong with using jiffies?
A lot of the (driver) users want a wallclock based timeout. For that,
miliseconds is a more obvious API with less chance to get the
On 23.07.2005 [15:29:42 +0200], Roman Zippel wrote:
Hi,
On Sat, 23 Jul 2005, Arjan van de Ven wrote:
jiffies/HZ is the more powerful API. The msec one which also sets
current to (un)interruptible is the simplified wrapper on top.
So why do you want to hide it? Make the jiffies based
Hi,
On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
set_current_state(TASK_{,UN}INTERRUPTIBLE);
schedule_timeout(msecs_to_jiffies(some_constant_msecs));
just have an interface that allows
schedule_timeout_msecs_{,un}interruptible(some_constant_msecs);
and push the
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
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
On 23.07.2005 [19:01:57 +0200], Roman Zippel wrote:
Hi,
On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
set_current_state(TASK_{,UN}INTERRUPTIBLE);
schedule_timeout(msecs_to_jiffies(some_constant_msecs));
just have an interface that allows
Hi,
On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
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
Hi,
On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
What's wrong with just:
schedule_timeout_{,un}interruptible(msecs_to_jiffies(some_constant_msecs));
Nothing, I suppose. I just prefer directly using msecs. I understand
your point more now, I think. You are worried about those
> How does something like this look? If this looks ok, I'll send out
> bunches of patches to add users of the new interfaces.
I'd drop the FASTCALL stuff... nowadays with regparm that's automatic
and the cost of register-vs-stack isn't too big anyway
Also I'd rather not add the non-msec
How does something like this look? If this looks ok, I'll send out
bunches of patches to add users of the new interfaces.
I'd drop the FASTCALL stuff... nowadays with regparm that's automatic
and the cost of register-vs-stack isn't too big anyway
Also I'd rather not add the non-msec ones...
44 matches
Mail list logo
