Re: [PATCH] alarmtimer: return EINVAL instead of ENOTSUPP if rtcdevdoesn't exist

From: KOSAKI Motohiro
Date: Thu Oct 17 2013 - 21:12:13 EST


(10/17/13 1:05 PM), John Stultz wrote:
On 10/14/2013 02:33 PM, kosaki.motohiro@xxxxxxxxx wrote:
From: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxxxxxxx>

Fedora Ruby maintainer reported latest Ruby doesn't work on Fedora Rawhide
on ARM. (http://bugs.ruby-lang.org/issues/9008)

Because of, commit 1c6b39ad3f (alarmtimers: Return -ENOTSUPP if no
RTC device is present) intruduced to return ENOTSUPP when
clock_get{time,res} can't find a RTC device. However it is incorrect.

Posix and Linux man pages agree that clock_gettime and clock_getres
should return EINVAL if clk_id argument is invalid. This is significant
different from timer_create API.

This patch fixes it.

Hrm... So I feel like there is a difference here. The clockid for
CLOCK_BOOTTIME_ALARM and CLOCK_REALTIME_ALARM are both valid.

Its just that they're not supported on this specific hardware because it
apparently lacks a RTC that has told the system it can be used as a
wakeup device (Its actually quite likely on the hardware that the RTC
can be a wakeup device, but that the driver is probably setting the
wakeup flag after the RTC registered - so there is probably a driver bug
here too).

So I feel like in this case EINVAL isn't quite right. I'll admit it is
somewhat new behavior, because we haven't had any clockids before that
were dependent on the particular hardware, they either existed in a
kernel verison or didn't.

Would updating the manpage be a better route?

Nope.

ENOTSUPP is not exported to userland. ENOTSUP (single P) and EOPNOTSUP is
valid errno (and they are same on linux), but ENOTSUPP is a kernel internal specific.

Moreover, I completely disagree your position. Both CLOCK_REALTIME_ALARM unsupported
kernel and ARM which doesn't support RTC should use the same error because application
need the same fallback.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/