On Thu, Sep 01, 2005 at 04:32:49PM +0200, Roman Zippel wrote:
> On Thu, 1 Sep 2005, Joe Korty wrote:
> > Kernel time sucks. It is just a single clock, it may not have
> > the attributes of the clock that the user really wished to use.
>
> Wrong. The kernel time is simple and effective for almost
Hi,
On Thu, 1 Sep 2005, Joe Korty wrote:
> On Thu, Sep 01, 2005 at 11:19:51AM +0200, Roman Zippel wrote:
>
> > You still didn't explain what's the point in choosing
> > different clock sources for a _timeout_.
>
> Well, if CLOCK_REALTIME is set forward by a minute,
> timers & timeout specified
On Thu, 2005-09-01 at 16:32 +0200, Roman Zippel wrote:
> Hi,
>
> On Thu, 1 Sep 2005, Joe Korty wrote:
>
> > > When you convert a user time to kernel time you can
> > > automatically validate
> >
> > Kernel time sucks. It is just a single clock, it may not have
> > the attributes of the clock th
On Thu, 2005-09-01 at 16:32 +0200, Roman Zippel wrote:
> Hi,
>
> On Thu, 1 Sep 2005, Joe Korty wrote:
>
> > > When you convert a user time to kernel time you can
> > > automatically validate
> >
> > Kernel time sucks. It is just a single clock, it may not have
> > the attributes of the clock th
Hi,
On Thu, 1 Sep 2005, Joe Korty wrote:
> > When you convert a user time to kernel time you can
> > automatically validate
>
> Kernel time sucks. It is just a single clock, it may not have
> the attributes of the clock that the user really wished to use.
Wrong. The kernel time is simple and e
On Thu, Sep 01, 2005 at 01:50:33AM +0200, Roman Zippel wrote:
> When you convert a user time to kernel time you can
> automatically validate
Kernel time sucks. It is just a single clock, it may not have
the attributes of the clock that the user really wished to use.
Joe
-
To unsubscribe from thi
On Thu, Sep 01, 2005 at 11:22:32AM +0200, Roman Zippel wrote:
> For a timeout? Please get real.
> If you need more precision, use a dedicated timer API, but don't make the
> general case more complex for the 99.99% of other users.
Struct timeout is just a struct timespec + a bit for absolute/rela
On Thu, Sep 01, 2005 at 11:19:51AM +0200, Roman Zippel wrote:
> You still didn't explain what's the point in choosing
> different clock sources for a _timeout_.
Well, if CLOCK_REALTIME is set forward by a minute,
timers & timeout specified against that clock will expire
a minute earlier than expe
Hi,
On Thu, 1 Sep 2005, Perez-Gonzalez, Inaky wrote:
> >You still didn't explain what's the point in choosing different clock
> >sources for a _timeout_.
>
> The same reasons that compel to have CLOCK_REALTIME or
> CLOCK_MONOTONIC, for example. Or the need to time out on a
> high resolution clo
>From: Roman Zippel [mailto:[EMAIL PROTECTED]
>On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
>
>> Hmm, I cannot think of more ways to specify a timeout than how
>> long I want to wait (relative) or until when (absolute) and which
>> is the reference clock. And they don't seem broken to me, comm
Hi,
On Wed, 31 Aug 2005, Daniel Walker wrote:
> > What "more versions" are you talking about? When you convert a user time
> > to kernel time you can automatically validate it and later you can use
> > standard kernel APIs, so you don't have to add even more API bloat.
>
> What's kernel time?
Hi,
On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
> Hmm, I cannot think of more ways to specify a timeout than how
> long I want to wait (relative) or until when (absolute) and which
> is the reference clock. And they don't seem broken to me, common
> sense, in any case. Do you have any examp
On Thu, 2005-09-01 at 01:50 +0200, Roman Zippel wrote:
> What "more versions" are you talking about? When you convert a user time
> to kernel time you can automatically validate it and later you can use
> standard kernel APIs, so you don't have to add even more API bloat.
What's kernel time? Ar
>From: Roman Zippel [mailto:[EMAIL PROTECTED]
>On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
>
>> I cannot produce (top of my head) any other POSIX API calls that
>> allow you to specify another clock source, but they are there,
>> somewhere. If I am to introduce a new API, I better make it
>>
Hi,
On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
> I cannot produce (top of my head) any other POSIX API calls that
> allow you to specify another clock source, but they are there,
> somewhere. If I am to introduce a new API, I better make it
> flexible enough so that other subsystems can u
>From: Roman Zippel [mailto:[EMAIL PROTECTED]
>On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
>
>> Usefulness: (see the rationale in the patch), but in a nutshell;
>> most POSIX timeout specs have to be absolute in CLOCK_REALTIME
>> (eg: pthread_mutex_timed_lock()). Current kernel needs the time
>From: Christopher Friesen [mailto:[EMAIL PROTECTED]
>Perez-Gonzalez, Inaky wrote:
>
>>>I can get the first sleep. Suppose I oversleep by X nanoseconds. I
>>>wake, and get an opaque timeout back. How do I ask for the new wake
>>>time to be "endtime + INTERVAL"?
>>
>>
>> endtime.ts += INTERVAL
>>
Perez-Gonzalez, Inaky wrote:
I can get the first sleep. Suppose I oversleep by X nanoseconds. I
wake, and get an opaque timeout back. How do I ask for the new wake
time to be "endtime + INTERVAL"?
endtime.ts += INTERVAL
[we all know opaque is relative too]
Heh. Okay, then what are the r
Hi,
On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
> >Why is that needed in a _general_ timeout API? What exactly makes it so
> >useful for everyone and not just more complex for everyone?
>
> Because if a system call gets a timeout specification it needs to
> verify its correctness first. In
>From: Christopher Friesen [mailto:[EMAIL PROTECTED]
>Joe Korty wrote:
>
>> The returned timeout struct has a bit used to mark the value as
absolute. Thus
>> the caller treats the returned timeout as a opaque cookie that can be
>> reapplied to the next (or more likely, the to-be restarted) timeout
>From: Roman Zippel [mailto:[EMAIL PROTECTED]
>On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
>
>> +flags = tp->clock_id & TIMEOUT_FLAGS_MASK;
>> +clock_id = tp->clock_id & TIMEOUT_CLOCK_MASK;
>> +
>> +result = -EINVAL;
>> +if (flags & ~TIMEOUT_RELATIVE)
>> +goto out;
>>
Hi,
On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
> + flags = tp->clock_id & TIMEOUT_FLAGS_MASK;
> + clock_id = tp->clock_id & TIMEOUT_CLOCK_MASK;
> +
> + result = -EINVAL;
> + if (flags & ~TIMEOUT_RELATIVE)
> + goto out;
> +
> + /* someday, we should support *all*
Joe Korty wrote:
The returned timeout struct has a bit used to mark the value as absolute. Thus
the caller treats the returned timeout as a opaque cookie that can be
reapplied to the next (or more likely, the to-be restarted) timeout.
Okay, endtime is always absolute value of when it should h
On Wed, Aug 31, 2005 at 03:20:03PM -0600, Christopher Friesen wrote:
> Perez-Gonzalez, Inaky wrote:
> >In this structure,
> >the user specifies:
> >whether the time is absolute, or relative to 'now'.
>
>
> >Timeout_sleep has a return argument, endtime, which is also in
> >'struct timeout' for
Perez-Gonzalez, Inaky wrote:
In this structure,
the user specifies:
whether the time is absolute, or relative to 'now'.
Timeout_sleep has a return argument, endtime, which is also in
'struct timeout' format. If the input time was relative, then
it is converted to absolute and returned th
On Wed, Aug 31, 2005 at 01:55:54PM -0700, Perez-Gonzalez, Inaky wrote:
> Hi Andrew
>
> This was developed by Joe Korty <[EMAIL PROTECTED]>, greatly
> enhancing something I had done before, so I am signing it out
> (although Joe should too, Joe?).
The fusyn (robust mutexes) project proposes the
Hi Andrew
I would like to ask for the inclusion of the general timeout
specification API in the -mm tree, looking forward it to bubble
up to mainline.
For more context, please visit:
http://groups.google.com/group/linux.kernel/browse_frm/thread/a426e5b0d0
f17860/b53000aa01304c4a?tvc=1&q=a+more
Hi John
>From: john stultz [mailto:[EMAIL PROTECTED]
>On Thu, 2005-07-28 at 18:52 -0700, Inaky Perez-Gonzalez wrote:
>> The main user of this new inteface is to allow system calls to get
>> time specified in an absolute form (as most of POSIX states) and thus
>> avoid extra time conversion work.
.
On Thu, 2005-07-28 at 18:52 -0700, Inaky Perez-Gonzalez wrote:
> The main user of this new inteface is to allow system calls to get
> time specified in an absolute form (as most of POSIX states) and thus
> avoid extra time conversion work.
>
> There was a short thread about it, available at google
Hi John
Couple of months ago Joe Korty sent the attached proposal for a new
interface and I was wondering if you could comment on it.
The main user of this new inteface is to allow system calls to get
time specified in an absolute form (as most of POSIX states) and thus
avoid extra time conversi
30 matches
Mail list logo
