netdev - Re: [PATCH v2 1/1] Added additional callback to ptp_clock

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]

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