[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1402202216350.4468@ionos.tec.linutronix.de>
Date: Thu, 20 Feb 2014 22:18:19 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: John Stultz <john.stultz@...aro.org>
cc: Alexey Perevalov <a.perevalov@...sung.com>,
linux-kernel@...r.kernel.org, anton@...sg.org,
kyungmin.park@...sung.com, cw00.choi@...sung.com,
akpm@...ux-foundation.org
Subject: Re: [PATCH v3 2/6] hrtimer: Add support for deferrable timer into
the hrtimer
On Thu, 20 Feb 2014, John Stultz wrote:
> On 02/20/2014 12:40 AM, Alexey Perevalov wrote:
> > diff --git a/include/uapi/linux/time.h b/include/uapi/linux/time.h
> > index e75e1b6..bb8dc60 100644
> > --- a/include/uapi/linux/time.h
> > +++ b/include/uapi/linux/time.h
> > @@ -56,6 +56,9 @@ struct itimerval {
> > #define CLOCK_BOOTTIME_ALARM 9
> > #define CLOCK_SGI_CYCLE 10 /* Hardware specific */
> > #define CLOCK_TAI 11
> > +#define CLOCK_REALTIME_DEFERRABLE 12
> > +#define CLOCK_MONOTONIC_DEFERRABLE 13
> > +#define CLOCK_BOOTTIME_DEFERRABLE 14
>
> Adding the deferrable HRTIMER bases above is right, but I don't think we
> agreed on adding the _DEFERRABLE clockids.
>
> I'd instead prefer you use add a new TIMER_DEFERABLE flags argument, and
> use the combination of the clockid + flag to decide which HRTIMER base
> is used.
And how does that work with anything else than timerfd? If we add
deferrable posix clocks then we add them for the other interfaces
which take a clockid as well.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists