On Tue, Nov 09, 2010 at 01:10:58PM -0800, john stultz wrote: > On Tue, 2010-11-09 at 09:23 +0100, Richard Cochran wrote: > > On Mon, Nov 08, 2010 at 03:37:03PM -0800, john stultz wrote: > > > So sort of minor nit here, but is there a reason the clockfd > > > implementation is primary here and the standard posix implementation > > > gets pushed off into its own function rather then doing something like: > > > > > > clk = clockid_to_clock_device(id) > > > if(clk) > > > return clockdev_clock_gettime(clk, user_ts); > > > [existing sys_clock_gettime()] > > > > > > As you implemented it, it seems to expect the clockdevice method to be > > > the most frequent use case, where as its likely to be the inverse. So > > > folks looking into the more common CLOCK_REALTIME calls have to traverse > > > more code then the likely more rare clockfd cases. > > > > Actually, what I would like to do is refactor the exisiting posix > > clock code to use the new framework. The idea is to have a set of > > static global clock_device*, one per fixed clock. The function > > clockid_to_clock_device() will include a lookup table, like this: > > > > static clock_device *realtime_clock, *monotinic_clock; > > > > switch (id) { > > case CLOCK_REALTIME: > > return realtime_clock; > > case CLOCK_MONOTONIC: > > return monotinic_clock; > > /* and so on ... */ > > } > > This seems a little over-reaching. I'm not sure I see what benefit would > come from having clock_devices for the static clock_ids? The extra mutex > locking and status/null checking for the clock_device would would just > add unnecessary overhead to the performance critical clock_gettime call. Okay, next time I'll leave the syscall in posix-timers.c and call out to the clock_device in the unlikely dynamic case. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html