netdev - Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.

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: <20100827160624.433b3374@lxorguk.ukuu.org.uk>
Date:	Fri, 27 Aug 2010 16:06:24 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Richard Cochran <richardcochran@...il.com>
Cc:	john stultz <johnstul@...ibm.com>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
	devicetree-discuss@...ts.ozlabs.org,
	linux-arm-kernel@...ts.infradead.org,
	Krzysztof Halasa <khc@...waw.pl>,
	Rodolfo Giometti <giometti@...ux.it>,
	Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.

> Sorry for causing confusion, but please understand "a hardware clock
> with timestamping capabilities than can be used for PTP support"
> whenever I wrote "PTP" or "PTP clock."

Ok that makes sense.
> 
> Well, what I just said is not entirely true.
> most are bound to the PTP protocol. That may change in the future...

Which seems fine to me too - its an implementation detail of that time
source.

> > Specialist applications will presumably need to know which time source or
> > sources they are tracking and synchronizing too out of multiple potential
> > PTP sources
> 
> Yes, the PTPd will have some special knowledge.

Not only that but consumers of different time synchronizations will need
to be able to describe which time source they want to talk about from a
selection of PTP or similar things.

> > system time bimble track a source makes sense just as with NTP but making
> > it a new clock seems the wrong model extending a non-too-bright API when
> > you can just put the time sources in a file tree.
> 
> Don't get your meaning here, what did you mean by "file tree?"

Something like

	/sys/class/timesource/<name>/...

at which point we don't have to enumerate them all, add special system
calls and then fret about the fact you can't access them from things like
shell scripts.

The fact SYS5.4 Unix and SuS got obsessed with numbering things
rather than using names unlike Unix doesn't mean it's the right model to
number them - usually the reverse is true, a heirarchy of file names is
rather more future proof.

Alan
--
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