linux-kernel - Re: [PATCHv4 13/17] ntp: add hardpps implementation

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: <20101121040531.5c7ba047@apollo.gnet>
Date:	Sun, 21 Nov 2010 04:05:31 +0300
From:	Alexander Gordeev <lasaine@....cs.msu.su>
To:	Rodolfo Giometti <giometti@...eenne.com>
Cc:	linux-kernel@...r.kernel.org,
	"Nikita V. Youshchenko" <yoush@...msu.su>,
	linuxpps@...enneenne.com,
	Andrew Morton <akpm@...ux-foundation.org>,
	John Stultz <johnstul@...ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCHv4 13/17] ntp: add hardpps implementation

В Sat, 20 Nov 2010 17:27:18 +0100
Rodolfo Giometti <giometti@...eenne.com> пишет:

> On Thu, Nov 18, 2010 at 07:01:06PM +0300, Alexander Gordeev wrote:
> > This commit adds hardpps() implementation based upon the original one
> > from the NTPv4 reference kernel code from David Mills. However, it is
> > highly optimized towards very fast syncronization and maximum stickness
> > to PPS signal. The typical error is less then a microsecond.
> > To make it sync faster I had to throw away exponential phase filter so
> > that the full phase offset is corrected immediately. Then I also had to
> > throw away median phase filter because it gives a bigger error itself
> > if used without exponential filter.
> > Maybe we will find an appropriate filtering scheme in the future but
> > it's not necessary if the signal quality is ok.
> 
> This patch (and follows) adds a new functionality to PPS subsystem, so
> let me suggest to you splitting in two parts this patch set: a first
> patch set who fixes up the current PPS implementation, and a second
> patch set who adds kernel consumer (and follows).

But the patches that add hardpps and parport client+generator depend on
the previous ones because the latter change lots of things in PPS
subsystem. I don't want to maintain them separately because we use all
of them in the production.

However I can tell here that it'll be ok for me if not all the patches
enter mainline at the same time. For example, patches 1-3 are already
ACKed and are actually bugfixes (patch 2 is trivial and patch 3 depends
on it) so I think they could be merged in the next rc. I placed them
in the beginning exactly for this reason. Whom should I mail them?

Same thing with other patches. Smaller patchset -> me (and probably
users) more happy. :)

-- 
  Alexander

Download attachment "signature.asc" of type "application/pgp-signature" (491 bytes)