linux-kernel - Re: [RFC][PATCH] timers: Make alarmtimer depend on CONFIG_RTC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1306919621.2353.164.camel@twins>
Date:	Wed, 01 Jun 2011 11:13:41 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	John Stultz <john.stultz@...aro.org>
Cc:	Richard Weinberger <richard@....at>, linux-kernel@...r.kernel.org,
	richard.cochran@...cron.at, tglx@...utronix.de, arnd@...db.de,
	toralf.foerster@....de
Subject: Re: [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
> 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.
--
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/