[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5d694706-1383-85ae-5a7e-2a32e4694df0@bluematt.me>
Date: Thu, 23 Feb 2023 17:18:06 -0800
From: Matt Corallo <ntp-lists@...tcorallo.com>
To: Richard Cochran <richardcochran@...il.com>
Cc: Miroslav Lichvar <mlichvar@...hat.com>,
chrony-dev@...ony.tuxfamily.org,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [chrony-dev] Support for Multiple PPS Inputs on single PHC
On 2/23/23 4:19 PM, Richard Cochran wrote:
> On Thu, Feb 23, 2023 at 12:56:34PM -0800, Matt Corallo wrote:
>
>> There's two separate questions here - multiple readers receiving the same
>> data, and multiple readers receiving data exclusively about one channel.
>>
>> I'd imagine the second is (much?) easier to implement, whereas the first is a bunch of complexity.
>
> This second idea would require a new API, so that user could select a
> particular channel.
>
> First idea would only change kernel behavior without changing the API.
Fair point. I figured a new IOCTL to filter was a lighter lift, even if a bunch of boilerplate to
define it.
I'm happy to take a crack at something to get the ball rolling, though not this week. I'm sure I
could copy+paste to make a new IOCTL work, but adding relevant queue limiting means I have to go
read much more kernel code to figure out which datastructures already exist there :).
It sounds like I should go replace the extts queue with a circular buffer, have every reader socket
store an index in the buffer, and new sockets read only futures pulses? I assume a new pulse already
wakes all select()ers on the sockets so nothing would need to change there. Is there some existing
code somewhere I should crib off of or just run and see where I get?
Thanks,
Matt
Powered by blists - more mailing lists