lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150708121737.GN25028@jcartwri.amer.corp.natinst.com>
Date:	Wed, 8 Jul 2015 07:17:37 -0500
From:	Josh Cartwright <joshc@...com>
To:	Richard Cochran <richardcochran@...il.com>
Cc:	Christopher Hall <christopher.s.hall@...el.com>,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	john.ronciak@...el.com, john.stultz@...aro.org, tglx@...utronix.de
Subject: Re: [PATCH v2 1/1] Added additional callback to ptp_clock_info:

On Wed, Jul 08, 2015 at 01:54:34PM +0200, Richard Cochran wrote:
> On Mon, Jul 06, 2015 at 03:44:58PM -0500, Josh Cartwright wrote:
> > It's difficult to make too many judgements without seeing how a driver
> > might implement this; is there another patchset that shows how a driver
> > implements this?
> 
> The interface is certainly clear enough to me.  The details of
> obtaining a cross time stamp from the hardware will remain hidden
> behind the interface in any case.

It's unusual to see interfaces added like this without also seeing users
at the same time to see how the pieces fit together.  Should I have
assumed this was a PATCH RFC for just the API?

I'm afraid this is the tip of a much larger iceberg.  If a device is
doing hardware crosstimestamping, what is the hardwares view of this
"system clock"?  How is it tied into the kernels' timekeeping?  How is
it ensured that same clock the hardware sees is the kernel's actively
selected clocksource?

You get this for free in software with getnstimeofday(), by pushing it
to hardware, the boundaries of responsibilities are all
unclear...without seeing the whole picture.

> > > -	int rsv[14];   /* Reserved for future use. */
> > > +	/* Whether the clock supports precise system-device cross timestamps */
> > > +	int precise_timestamping;
> >
> > Perhaps now is a good time to add an unsigned int 'flags' member instead,
> > and start allocating bits.
>
> Considering the rate of growth for the PHC stuff, I am not worried
> about spending a whole 'int' on this.

Fair enough!

Thanks,

  Josh
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ