Re: [PATCH RFC 2/8] clock device: convert clock_gettime
flat view
From: Richard Cochran <hidden>
Date: 2010-11-15 09:42:03
Also in:
lkml
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:quoted
On Mon, Nov 08, 2010 at 03:37:03PM -0800, john stultz wrote:quoted
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