On 10/18/2013 6:39 PM, John Stultz wrote: > On 10/17/2013 06:12 PM, KOSAKI Motohiro wrote: >> (10/17/13 1:05 PM), John Stultz wrote: >>> On 10/14/2013 02:33 PM, kosaki.motoh...@gmail.com wrote: >>>> From: KOSAKI Motohiro <kosaki.motoh...@jp.fujitsu.com> >>>> >>>> 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. > > Ok. You're right. The technicality that the clockid is valid but > unsupported isn't really useful to the applications, since the effect is > the same. > > What is the urgency on this? As the issue has been around since 3.0, is > it ok if it gets queued for 3.13 and marked for stable, or does it need > to land in 3.12?
3.13 is OK to me. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
