> > 1. character device (like hpet) > > 2. posix clock api > > 3. sysfs > > > > Or possibly some combination of the three. > > I fail to see the requirement for any of those. Either the hardware > clock is suitable as a clocksource for general consumption, then it > should just be used as a clock source. If it's not - e.g. because it's > too slow to access - then it just should serve as a reference in the > NTP style and steer the timekeeping into sync. I think you are confusing clocks, time stamps and the system time. System time is a single default reference source defined by POSIX in terms of sort of UTC. There are lots of other time sources which don't necessarily tally with oen another and there are times you have to respect more than one of them because you are not the master clock nor can you dictate synchronization between the two pieces of infrastructure you span Consider a large rock gig - your control systems for the speakers and PA are tightly synchronized and delivering audio with very precise delays to different amp/speaker combinations. At the same time if you are managing effects and the like then the instrument timings for those will be coming off another clock, which is also very precise and differently sourced. So what we actually have is - multiple input devices that report timestamps (the PC clock, GPS, PTP, time synchronized busses, synchronous ethernet, network provided reports etc) - some of those inputs get turned into clocks with varying degrees of hardware and software processing which are consumed by various bits of software and drivers - a subset of those clocks in some form are algmated into a generic system time. which provides a meaningful representation of general time to the majority of apps that simple can't care less Apps and drivers need access to all three layers. -- 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