[lkml]   [2011]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH] timers: Make alarmtimer depend on CONFIG_RTC_CLASS
On Tue, 2011-05-31 at 23:38 -0700, John Stultz wrote:
> On Sun, 2011-05-29 at 12:48 +0200, Richard Weinberger wrote:
> > The alarmtimer interface makes IMHO only sense when a RTC device
> > is available.
> > On systems with !CONFIG_RTC_CLASS (like UML) the warning
> > "Kernel not built with RTC support, ALARM timers will not wake from suspend"
> > is annoying.
> Yea.
> The tradeoff with this patch is that applications that use
> I'm mixed here, since we probably want to communicate to the application
> that the alarm timers aren't going to wake us up, but also I suspect
> most applications won't handle the -EINVAL properly, so I had allowed
> for the clockids to still work as long as we didn't suspend.
> I'm leaning more towards just returning EINVAL as you suggest, since
> really the functionality isn't there. But I'm thinking possibly doing so
> if no RTCs are detected at runtime (rather then using all the ifdefs you
> do).
> Thoughts from anyone else?

Wouldn't -ENOTSUPP be a better return value than -EINVAL? But yeah, I
think simply returning an error is fine, if apps don't check for that,
they're broken, simple as that, we can't possibly avoid all userspace
problems by adding more kernel code.

 \ /
  Last update: 2011-06-01 14:25    [W:0.067 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site