Messages in this thread | | | From | Kyle Moffett <> | Date | Tue, 21 Sep 2010 16:47:45 -0400 | Subject | Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks. |
| |
On Fri, Aug 27, 2010 at 18:30, John Stultz <johnstul@us.ibm.com> wrote: > On one side, there is the view that the kernel should abstract and hide > the hardware details to increase app portability. And the other is that > the raw hardware details should be exposed, so the OS stays out of the > way. > > Neither of these views are always right. Ideally we can come up with a > abstracted way to provide the hardware data needed that's generic enough > that applications don't have to be changed when moving between hardware > or configurations. > > The posix clock id interface is frustrating because the flat static > enumeration is really limiting. > > I wonder if a dynamic enumeration for posix clocks would be possibly a > way to go?
Well how about something much more straightforward:
#define CLOCK_FD 0x80000000 fd = open("/dev/clocks/some_clock_name", O_RDONLY); clock_gettime(CLOCK_FD | fd, &ts);
This would provide all of the standard character-device semantics that everyone is accustomed to, and furthermore you could allow non-root users to manage specific clocks using just DAC permission bits.
You'd still probably need to add a clock_adjtimex() syscall, but it could easily fail with EINVAL for software or per-thread clocks, but that seems like it would nicely abstract the hardware without forcing a numeric address space.
Cheers, Kyle Moffett
| |