On Thu, 2010-09-09 at 12:49 +0200, Thomas Gleixner wrote: > On Fri, 3 Sep 2010, Richard Cochran wrote: > > This patch needs to be split in pieces. The syscall change is totally > unrelated to the dynamic clock id creation. Though I do not like > either of them. :) > > > A new syscall is introduced that allows tuning of a POSIX clock. The > > syscall is implemented for four architectures: arm, blackfin, powerpc, > > and x86. > > > > The new syscall, clock_adjtime, takes two parameters, the clock ID, > > and a pointer to a struct timex. The semantics of the timex struct > > have been expanded by one additional mode flag, which allows an > > absolute offset correction. When specificied, the clock offset is > > immediately corrected by skipping to the new time value. > > And why do we need a separate syscall for this? > > > In addition, the POSIX clock code has been augmented to offer a > > dynamic clock creation method. Instead of registering a hard > > coded clock ID, modules may call create_posix_clock(), which > > returns a new clock ID. > > This has been discussed for years and I still fail to see the > requirement for this. The only result is that it allows folks to > create their special purpose clock stuff and keep it out of tree > instead of fixing the problems they have with the existing clock > infrastructure in the kernel. > > As far as I understood from the previous discussions, the final goal > is to provide PTP support, right? > > But what I see is an approach which tries to implement disconnected > special purpose clocks which have the ability to be adjusted > independently. What's the purpose of this ? Why can't we just use the > existing clocks and make PTP work on them ? So this too was my initial gut response. It seems ridiculous to expose two clock_ids (CLOCK_REALTIME and CLOCK_PTP)that conceptually represent the same thing (ie: number of seconds,nanoseconds since 1970). It doesn't help that one of the use cases that Richard suggests is "for example in an embedded control application. The userland software can simply ignore the wrong system time." As someone who's spent a *lot* of time trying to fix the "wrong system time" these use cases reek of work-around solutions instead of properly fixing whatever keeps the system time from being accurately sycned. However, as I've worked on understanding the issue, I realize that there is some validity to needing to expose more then one hardware clock the conceptually is the same as CLOCK_REALTIME. And that most of my gut reaction to this was me being a bit oversensitive. :) > I know that lots of embedded folks think that they need their special > timers and extra magic to make stuff work, but that's the wrong > approach. > > What's wrong with the existing clocks? Nothing, except that we have no > way to sync CLOCK_MONOTONIC across several machines. And that's what > you really want if you try to do distributed control and data > acquisition stuff. Err.. s/CLOCK_MONOTONIC/CLOCK_REALTIME/ :) > That's a single CLOCK_MONOTONIC_GLOBAL and not a bunch of completely > disconnected clock implementations with random clock ids and random > feature sets. Specifically, because the way the correction feedback loops work with PTP, working against the hardware clock that is generating the timestamps directly is going to get the best results. Additionally, it allows multiple syncing methods to be tried in userland, rather then trying jam it all in the kernel in order to make it look like there is only one global system time. The parallel with audio hardware is also valid, as we currently ignore any skew between audio hardware clocks and system time, as there's no useful way to expose those clocks (that I'm aware of atleast, not too familiar with alsa, but my googling didn't show much). However, since there may be multiple PTP clocks or audio clocks or whatever, allocating static clockids for each type isn't quite useful, as we need to deal with mapping the clockids to hardware. So exposing the clockids via sysfs allows us to understand the physical mapping of what bus and device the clock hangs off of. Now, I'm not a fan of the clockid directory that Richard proposed, I'd rather add a clock_id to the devices sysfs entry. But these are details and can be worked out as the patch gets refined. thanks -john -- 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
