netdev - Re: [very-RFC 0/8] TSN driver for the kernel

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: <3650675.mUADb08Tiz@wuerfel>
Date:	Mon, 13 Jun 2016 15:12:24 +0200
From:	Arnd Bergmann <arnd@...aro.org>
To:	Richard Cochran <richardcochran@...il.com>
Cc:	Henrik Austad <henrik@...tad.us>, linux-kernel@...r.kernel.org,
	linux-media@...r.kernel.org, alsa-devel@...r.kernel.org,
	netdev@...r.kernel.org, henrk@...tad.us
Subject: Re: [very-RFC 0/8] TSN driver for the kernel

On Monday, June 13, 2016 1:47:13 PM CEST Richard Cochran wrote:
> * Kernel Space
> 
> 1. Providing frames with a future transmit time.  For normal sockets,
>    this can be in the CMESG data.  For mmap'ed buffers, we will need a
>    new format.  (I think Arnd is working on a new layout.)
> 

After some back and forth, I think the conclusion for now was that
the timestamps in the current v3 format are sufficient until 2106
as long as we treat them as 'unsigned', so we don't need the new
format for y2038, but if we get a new format, that should definitely
use 64-bit timestamps because that is the right thing to do.

	Arnd