On Tuesday 20 October 2015 10:59:34 Jesper Nilsson wrote:
> On Tue, Oct 20, 2015 at 10:18:22AM +0200, Arnd Bergmann wrote:
> > On Monday 19 October 2015 11:53:25 John Stultz wrote:
> > >
> > > But yea. At the same time I get you want to avoid user-pain like in
> > > the case of the badly
On Tue, Oct 20, 2015 at 10:18:22AM +0200, Arnd Bergmann wrote:
> On Monday 19 October 2015 11:53:25 John Stultz wrote:
> >
> > But yea. At the same time I get you want to avoid user-pain like in
> > the case of the badly initialized RTC, but in that case would
> > returning 0 for RTC reads
On Monday 19 October 2015 11:53:25 John Stultz wrote:
>
> But yea. At the same time I get you want to avoid user-pain like in
> the case of the badly initialized RTC, but in that case would
> returning 0 for RTC reads greater then y2038 on 32 bit systems be a
> more sane fix?
I like that idea.
On Mon, Oct 19, 2015 at 11:53:25AM -0700, John Stultz wrote:
> On Fri, Oct 9, 2015 at 1:25 AM, Jesper Nilsson
> wrote:
> > Of course, the proposed patch only allows the setting of relative
> > timeouts with TFD_TIMER_CANCEL_ON_SET, any application using
> > it would also need to be patched to
On Mon, Oct 19, 2015 at 11:53:25AM -0700, John Stultz wrote:
> On Fri, Oct 9, 2015 at 1:25 AM, Jesper Nilsson
> wrote:
> > Of course, the proposed patch only allows the setting of relative
> > timeouts with TFD_TIMER_CANCEL_ON_SET, any application using
> > it would also
On Tue, Oct 20, 2015 at 10:18:22AM +0200, Arnd Bergmann wrote:
> On Monday 19 October 2015 11:53:25 John Stultz wrote:
> >
> > But yea. At the same time I get you want to avoid user-pain like in
> > the case of the badly initialized RTC, but in that case would
> > returning 0 for RTC reads
On Tuesday 20 October 2015 10:59:34 Jesper Nilsson wrote:
> On Tue, Oct 20, 2015 at 10:18:22AM +0200, Arnd Bergmann wrote:
> > On Monday 19 October 2015 11:53:25 John Stultz wrote:
> > >
> > > But yea. At the same time I get you want to avoid user-pain like in
> > > the case of the badly
On Monday 19 October 2015 11:53:25 John Stultz wrote:
>
> But yea. At the same time I get you want to avoid user-pain like in
> the case of the badly initialized RTC, but in that case would
> returning 0 for RTC reads greater then y2038 on 32 bit systems be a
> more sane fix?
I like that idea.
On Fri, Oct 9, 2015 at 1:25 AM, Jesper Nilsson wrote:
> Allow TFD_TIMER_CANCEL_ON_SET on timerfd_settime() with relative
> as well as absolute timeout.
>
> Signed-off-by: Jesper Nilsson
> ---
> Resending after some discussion with Thomas Gleixner at ELCE,
> and Cc:ing John Stultz and Michael
On Fri, Oct 9, 2015 at 1:25 AM, Jesper Nilsson wrote:
> Allow TFD_TIMER_CANCEL_ON_SET on timerfd_settime() with relative
> as well as absolute timeout.
>
> Signed-off-by: Jesper Nilsson
> ---
> Resending after some discussion with Thomas Gleixner
Allow TFD_TIMER_CANCEL_ON_SET on timerfd_settime() with relative
as well as absolute timeout.
Signed-off-by: Jesper Nilsson
---
Resending after some discussion with Thomas Gleixner at ELCE,
and Cc:ing John Stultz and Michael Kerrisk who may have comments.
Longer background:
One of the uses for
Allow TFD_TIMER_CANCEL_ON_SET on timerfd_settime() with relative
as well as absolute timeout.
Signed-off-by: Jesper Nilsson
---
Resending after some discussion with Thomas Gleixner at ELCE,
and Cc:ing John Stultz and Michael Kerrisk who may have comments.
Longer
Allow TFD_TIMER_CANCEL_ON_SET on timerfd_settime() with relative
as well as absolute timeout.
Signed-off-by: Jesper Nilsson
---
Longer background:
One of the uses for TFD_TIMER_CANCEL_ON_SET is to get
an event when the CLOCK_REALTIME changes (as by NTP or user action).
In this case, the timeout
Allow TFD_TIMER_CANCEL_ON_SET on timerfd_settime() with relative
as well as absolute timeout.
Signed-off-by: Jesper Nilsson
---
Longer background:
One of the uses for TFD_TIMER_CANCEL_ON_SET is to get
an event when the CLOCK_REALTIME changes (as by NTP or user action).
14 matches
Mail list logo