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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 11 Sep 2014 11:52:45 +0200 From: Daniel Glöckner <dg@...ix.com> To: Richard Cochran <richardcochran@...il.com> Cc: netdev@...r.kernel.org Subject: Re: PTP_PEROUT_REQUEST and clock stepping On Wed, Sep 10, 2014 at 07:26:20PM +0200, Richard Cochran wrote: > On Wed, Sep 10, 2014 at 06:16:37PM +0200, Daniel Glöckner wrote: > > I was wondering how periodic output is supposed to behave if the clock > > is stepped from a time after ptp_perout_request.start to a time before > > ptp_perout_request.start. > > I would say the result is undefined. > > User space should first stop the periodic output, then reprogram the > clock, then restart the periodic output. Anything else makes no sense > at all. But then the PTP demon has to be responsible for configuring the periodic outputs as well. IMHO there is no use for a .start value > .period. It is good for defining the phase of the periodic output but is just annoying if you want to have the periodic output running all the time. Only a small fraction of people using periodic outputs will want to schedule the start of the signal at a specific time in the future and only a fraction of those will use a .period value that is so small that they can't use a timer to configure the periodic output within .period/2 before the desired start time. Best regards, Daniel -- Dipl.-Math. Daniel Glöckner, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11, Bertha-von-Suttner-Straße 9, 37085 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Dr. Uwe Kracke, Ust-IdNr.: DE 205 198 055 emlix - your embedded linux partner -- 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