public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Richard Cochran <richardcochran@gmail.com>
Cc: linuxppc-dev@lists.ozlabs.org,
	Rodolfo Giometti <giometti@linux.it>,
	netdev@vger.kernel.org, devicetree-discuss@lists.ozlabs.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Krzysztof Halasa <khc@pm.waw.pl>
Subject: Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
Date: Tue, 17 Aug 2010 09:25:55 +0000	[thread overview]
Message-ID: <201008170925.55592.arnd@arndb.de> (raw)
In-Reply-To: <20100817083216.GA3330@riccoc20.at.omicron.at>

On Tuesday 17 August 2010, Richard Cochran wrote:
> > Why did you not want to add syscalls? Adding ioctls instead of syscalls
> > does not make the interface better, just less visible.
> 
> I bet that, had I posted patch set with new syscalls, someone would
> have said, "You are adding new syscalls. Can't you just use a char
> device instead!"

Very possible, but after considering both options, I think we would
still end up with the same conclusion.
 
> If you add syscalls and introduce CLOCK_PTP, then you add it to
> everyone's kernel, even those people who never heard of PTP. A char
> device has the advantage that can it be simply ignored.

It's a matter of perspective whether you consider this an advantage
or disadvantage. I would expect that since you are trying to get support
for PTP into the kernel, you'd be happy for people to know about it and
use your code ;-).

> Also, a syscall has got to have the right form from the very beginning.
> If the next generation of PTP hardware looks very different, then it is not
> that much of a crime to change an ioctl interface, provided it has
> versioning.

No, that's just a myth. The rules for ABI stability are pretty much the
same. We try hard to avoid ever changing an existing ABI, for both
syscalls and ioctl. In either case, if you get it wrong, you have to support
the old interface and create a new syscall or ioctl command.
As mentioned, versioning does not solve this, it just adds another
indirection (which we try to avoid).

One difference is that more people take a look at your code when you suggest
a new syscall, so the chances of getting it right in the first upstream
version are higher.
Another difference is that we generally use ioctl for devices that can
be enumerated, while syscalls are for system services that are not tied to
a specific device. This argument works both ways for PTP IMHO: On the one
hand you want to have a reliable clock that you can use without knowing
where it comes from, on the other you might have multiple PTP sources that
you need to differentiate.

	Arnd

  reply	other threads:[~2010-08-17  9:26 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-16 11:17 [PATCH v5 0/5] ptp: IEEE 1588 clock support Richard Cochran
2010-08-16 11:17 ` [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks Richard Cochran
2010-08-16 14:26   ` Arnd Bergmann
2010-08-16 19:00     ` Richard Cochran
2010-08-16 19:59       ` Arnd Bergmann
2010-08-17  8:32         ` Richard Cochran
2010-08-17  9:25           ` Arnd Bergmann [this message]
2010-08-17 10:52             ` Richard Cochran
2010-08-17 11:36               ` Arnd Bergmann
2010-08-18  0:40                 ` john stultz
2010-08-18 14:04                 ` Richard Cochran
2010-08-18 15:02                   ` Arnd Bergmann
2010-08-19  9:22                     ` Richard Cochran
2010-08-19 12:29                       ` Arnd Bergmann
2010-08-19 15:23                         ` Ira W. Snyder
2010-08-19 15:48                           ` Arnd Bergmann
2010-08-16 19:24   ` john stultz
2010-08-16 19:38     ` john stultz
2010-08-17  8:53     ` Richard Cochran
2010-08-18  0:22       ` john stultz
2010-08-18  7:19         ` Richard Cochran
2010-08-19  0:12           ` john stultz
2010-08-19  5:55             ` Richard Cochran
2010-08-19 12:28               ` Arnd Bergmann
2010-08-19 15:38                 ` Richard Cochran
2010-08-23 20:21                   ` john stultz
2010-08-27 11:08                     ` Richard Cochran
2010-08-27 12:03                       ` Arnd Bergmann
2010-08-27 20:56                         ` John Stultz
2010-08-27 12:45                       ` Alan Cox
2010-08-27 20:14                       ` John Stultz
2010-08-23 20:08               ` john stultz
2010-08-24 18:30                 ` Stephan Gatzka
2010-08-25  9:40                 ` Christian Riesch
2010-08-27  1:57                   ` john stultz
2010-08-27  7:57                     ` Richard Cochran
2010-08-27 12:41                       ` Alan Cox
2010-08-27 14:02                         ` Richard Cochran
2010-08-27 14:50                           ` Alan Cox
2010-08-27 15:35                           ` M. Warner Losh
2010-08-29 13:32                         ` Christian Riesch
2010-08-27 12:38                 ` Richard Cochran
2010-08-27 13:38                   ` Alan Cox
2010-08-27 14:34                     ` Richard Cochran
2010-08-27 15:06                       ` Alan Cox
2010-08-27 15:21                         ` Patrick Loschmidt
2010-08-27 22:30                   ` John Stultz
2010-09-06  6:33                     ` Richard Cochran
2010-09-21 16:54                       ` Stephan Gatzka
2010-09-21 20:47                     ` Kyle Moffett
2010-09-22 10:14                       ` Richard Cochran
2010-08-16 11:18 ` [PATCH 2/5] ptp: Added a clock that uses the Linux system time Richard Cochran
2010-08-16 11:18 ` [PATCH 3/5] ptp: Added a clock that uses the eTSEC found on the MPC85xx Richard Cochran
2010-08-16 11:18 ` [PATCH 4/5] ptp: Added a clock driver for the IXP46x Richard Cochran
2010-08-16 11:19 ` [PATCH 5/5] ptp: Added a clock driver for the National Semiconductor PHYTER Richard Cochran

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=201008170925.55592.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=giometti@linux.it \
    --cc=khc@pm.waw.pl \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=netdev@vger.kernel.org \
    --cc=richardcochran@gmail.com \
    /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