netdev - Re: [PATCH 1/2] posix clocks: introduce a syscall for clock tuning.

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: <20100910092303.GA10179@riccoc20.at.omicron.at>
Date:	Fri, 10 Sep 2010 11:23:03 +0200
From:	Richard Cochran <richardcochran@...il.com>
To:	john stultz <johnstul@...ibm.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>, netdev@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>, linux-api@...r.kernel.org,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH 1/2] posix clocks: introduce a syscall for clock tuning.

On Thu, Sep 09, 2010 at 03:53:13PM -0700, john stultz wrote:
> The only problem there is from the examples, it seems some PTP hardware
> can be fairly self-contained. So its a actual ns clock that can be freq
> adjusted in hardware, not a constant freq counter that is then converted
> to nanoseconds and freq managed in software. So the interface probably
> can't be quite as low-level as the clocksource/clockevent structures.
> 
> In fact, from the example drivers posted already, it looks like the
> k_clock structure maps fairly close to what the hardware uses.

Yes, thats right. The PTP hardware clocks of which I know all follow
the same pattern.

> Other clock types that we may want to expose, such as the RTC also can
> map fairly close to k_clock. The audio clocks may need some research, as
> I suspect they're just a clocksource style counter, so some additional
> software cycle->ns layering similar to the timekeeping core (but likely
> much simpler) may be needed.

We may also find clocks that are free running counters which can
timestamp network packets. In that case, one would also need software
support to implement rate adjustment. I have not seen that yet among
PTP hardware clocks, so I think we should cross that bridge when we
come to it. In any case, the proposed infrastructure does not exclude
the possibility to support that kind of clock.

> So the question to Richard is, what does the above k_clock not provide
> that the PTP driver needs?

Yes.

> If you've already made some stabs at it,
> seeing an example of the generic header and a trivial example driver
> that includes the k_clock structure, so we can see what it removed from
> your earlier chardev implementation would be helpful.

Okay, it seems that we are gradually coming around to a workable
solution. I will repost the posix clock idea including the PTP clock
drivers, so you all can see how it would fit together.

Thanks,
Richard
--
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