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]

Message-ID: <20110301153809.GA2934@siel.b>
Date:	Tue, 1 Mar 2011 16:38:09 +0100
From:	torbenh <torbenh@....de>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	John Stultz <john.stultz@...aro.org>,
	Richard Cochran <richard.cochran@...cron.at>,
	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, Feb 01, 2011 at 01:50:55PM -0000, Thomas Gleixner wrote:
> This is a rework of Richards PTP support series core code. The PTP
> driver patches are unchanged and not included in this series.
> 
> The reason for this rework is that I got scared when reviewing:
>  [PATCH V10 09/15] posix clocks: cleanup the CLOCK_DISPTACH macro
> 
> The patch is really too large and the risk of wreckage too high. So
> instead of whipping Richard through another round I reworked the
> series in the following way:
> 
> 1) Split the CLOCK_DISPATCH cleanup in fine grained steps.
>    
>    That allowed further cleanups and got rid of 200 lines of code and
>    made a lot of functions static.
>    
>    It also fixes subtle changes to the error return codes which happened
>    in the large all in one overhaul (EINVAL vs. ENOTSUP).
>    
> 2) Move the patches which add new functionality after the cleanup.
> 
>    It does not make sense to add new functionality into the old scheme
>    first and then clean it up.
> 
> 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.


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