Messages in this thread | | | Subject | Re: [RFC][PATCH] timers: Make alarmtimer depend on CONFIG_RTC_CLASS | From | Peter Zijlstra <> | Date | Wed, 01 Jun 2011 11:13:41 +0200 |
| |
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 > CLOCK_REALTIME_ALARM or CLOCK_BOOTTIME_ALARM will then get -EINVAL. > > 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.
| |