From: Richard Cochran <richardcochran@gmail.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-api@vger.kernel.org, john stultz <johnstul@us.ibm.com>
Subject: Re: [PATCH 0/2] [RFC] posix clock tuning
Date: Thu, 9 Sep 2010 14:21:56 +0200 [thread overview]
Message-ID: <20100909122156.GA2823@riccoc20.at.omicron.at> (raw)
In-Reply-To: <alpine.LFD.2.00.1009091152300.2477@localhost6.localdomain6>
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
next prev parent reply other threads:[~2010-09-09 12:22 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-03 9:27 Richard Cochran
2010-09-03 9:29 ` [PATCH 1/2] posix clocks: introduce a syscall for " Richard Cochran
2010-09-03 9:58 ` Richard Cochran
2010-09-04 14:06 ` Richard Cochran
2010-09-09 10:49 ` Thomas Gleixner
2010-09-09 13:34 ` Richard Cochran
2010-09-09 20:10 ` Thomas Gleixner
2010-09-09 21:16 ` Thomas Gleixner
2010-09-09 22:53 ` john stultz
2010-09-10 9:23 ` Richard Cochran
2010-09-09 21:01 ` john stultz
2010-09-09 21:31 ` Thomas Gleixner
2010-09-03 9:30 ` [PATCH 2/2] posix clocks: introduce a sysfs presence Richard Cochran
2010-09-09 22:19 ` john stultz
2010-09-09 23:00 ` Alan Cox
2010-09-10 9:31 ` Richard Cochran
2010-09-11 0:20 ` Greg KH
2010-09-04 17:23 ` [PATCH 0/2] [RFC] posix clock tuning Christoph Lameter
2010-09-04 17:48 ` Christian Riesch
2010-09-05 1:37 ` Christoph Lameter
2010-09-05 5:56 ` Richard Cochran
2010-09-05 1:47 ` Christoph Lameter
2010-09-05 6:22 ` Richard Cochran
2010-09-05 7:20 ` Richard Cochran
2010-09-05 23:13 ` Christoph Lameter
2010-09-06 7:09 ` Richard Cochran
2010-09-09 9:58 ` Thomas Gleixner
2010-09-09 12:21 ` Richard Cochran [this message]
2010-09-09 12:50 ` Thomas Gleixner
2010-09-09 15:02 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100909122156.GA2823@riccoc20.at.omicron.at \
--to=richardcochran@gmail.com \
--cc=johnstul@us.ibm.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®