Re: [PATCH 0/2] [RFC] posix clock tuning

[Richard Cochran]

On Thu, Sep 09, 2010 at 11:58:09AM +0200, Thomas Gleixner wrote:
> On Fri, 3 Sep 2010, Richard Cochran wrote:
> 
> > Recently on the lkml, we discussed how to allow adjustment of posix
> > clocks. I have tried to understand and implement the ideas expressed
> > in the various threads.
> 
> Cc'ing the relevant maintainers to such discussions and patches might
> be helpful. Seems I need to do some archive digging.

Sorry about that. Still learning how to work on the list.  The story
so far is...

** PTP hardware clock as a character device (54 messages)

   http://lkml.org/lkml/2010/8/16/90

   The general mood of this was something like: "You have made a
   chardev for PTP clocks. The ioctls look similar to the posix clock
   api. Why not just use the posix api?"

** posix clock tuning syscall, static clockid (13 messages)

   http://lkml.org/lkml/2010/8/23/49

   The general mood of this one was: "I don't like a static clockid
   for PTP clocks. But a dynamic id would be just fine."

** posix clock tuning syscall, dynamic clockid (16 messages)

   http://lkml.org/lkml/2010/9/3/119 (This thread)

   The mood seems to be, "why not use a chardev for that?"

>From my point of view, the discussion is going round in circles. There
seems to be agreement that supporting PTP hardware clocks is a good
idea. The objections seem to be about the form of the API. In general,
there are three avenues.

1. character device (like hpet)
2. posix clock api
3. sysfs

Or possibly some combination of the three.

I have my preference, but I am willing to work it according to
taste. Would you have some preference?

> > If there is agreement on this approach, I will resubmit these two
> > patches as part of a longer series, including support for a new kind
> > of hardware clock, so you can see how it all fits together. But first,
> > I would like to concentrate on the new syscall itself.
> > 
> > The patches are against a recent net-next tree. Please don't worry if
> > the syscall tables are not quite up to date. I can fix that later.
> 
> How is this related to net-next ? 

The whole hardware timestamping and PTP clock issue is somewhat
network related. In particular, needed to start there to get some
background support for timestamping within PHY devices.

Thanks,

Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/