linux-kernel - Re: [patch 00/28] Rework of the PTP support series core code

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, 2 Mar 2011 10:41:59 +0100
From:	torbenh <torbenh@....de>
To:	Richard Cochran <richard.cochran@...cron.at>
Cc:	'Thomas Gleixner' <tglx@...utronix.de>,
	'LKML' <linux-kernel@...r.kernel.org>,
	'John Stultz' <john.stultz@...aro.org>,
	'Ingo Molnar' <mingo@...e.hu>,
	'Peter Zijlstra' <peterz@...radead.org>
Subject: Re: [patch 00/28]  Rework of the PTP support series core code

On Tue, Mar 01, 2011 at 07:50:55PM +0100, Richard Cochran wrote:
> >> Richard, can you please run that through your testing ? The PTP
> >> drivers apply on top of that.
> >
> >i am a bit puzzled how a software ptp clock would fit into this
> >framework. for some avb use-cases we could get away with a ptp clock
> >thats only accurate to a few 100us.
> >
> >from a few quick glances it seems, that if userspace is able to create a
> >ptp clock driven by normal timers and the kernel allows for timestamping
> >packets using that clock, a modified ptpd could do the trick.
> >
> >i am not sure, how much of this should be happening in userspace though.
> 
> The point of the PHC patch set is to support special hardware clocks.
> After much discussion (see the links in the V12 patch set) we have come
> up with an API that will work both with software only (ie normal system
> time) as well as with hardware clocks.
> 
> The application just uses: clockid_t id = CLOCK_REALTIME
> if it wants to use software time stamping with the normal system clock.

this assumes, that the ptp master clock is actually suitable to be
CLOCK_REALTIME. i am not sure if this assumption holds true, when the
master clock is an audio clock, of some cheap soundcard.

in that case, we need to relate the audio clock to CLOCK_REALTIME.
thats surely possible, but we end up with 2 cascaded clock servos.

additionally userspace must then manage to get the master clocks
relations from the ptpd to the app that plays out the audio.

if i was using a h/w clock, i could just make the audio playing app
query the h/w ptp clock using the right clockid.

so it looks like i would end up with a different api on the audio side.

> 
> I have some patches for the ptpd that show how the API works, and I
> will be reposting those to the ptpd.sf.net in the next few days.
> 
> HTH,
> Richard
> 

-- 
torben Hohn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/