[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5306718E.9080803@linaro.org>
Date: Thu, 20 Feb 2014 13:20:14 -0800
From: John Stultz <john.stultz@...aro.org>
To: Thomas Gleixner <tglx@...utronix.de>
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 02/20/2014 01:18 PM, Thomas Gleixner wrote:
> 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.
Other interfaces have flag arguments as well (for things like
TIMER_ABSTIME).
thanks
-john
--
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