On Tue, Nov 28, 2017 at 3:08 PM, Willem de Bruijn
wrote:
> On Tue, Nov 28, 2017 at 3:46 AM, Arnd Bergmann wrote:
>> On Tue, Nov 28, 2017 at 8:04 AM, Björn Töpel wrote:
>>> 2017-11-27 21:51 GMT+01:00 Arnd Bergmann :
>>> [...]
> There already is an effort to come up with a new AF_PACKET V4 [1]
On Tue, Nov 28, 2017 at 3:46 AM, Arnd Bergmann wrote:
> On Tue, Nov 28, 2017 at 8:04 AM, Björn Töpel wrote:
>> 2017-11-27 21:51 GMT+01:00 Arnd Bergmann :
>> [...]
There already is an effort to come up with a new AF_PACKET V4 [1].
We should make sure that any new interface does not have
On Tue, Nov 28, 2017 at 8:04 AM, Björn Töpel wrote:
> 2017-11-27 21:51 GMT+01:00 Arnd Bergmann :
> [...]
>>> There already is an effort to come up with a new AF_PACKET V4 [1].
>>> We should make sure that any new interface does not have the
>>> Y2038/Y2106 issue. But, if a new version is being dev
2017-11-27 21:51 GMT+01:00 Arnd Bergmann :
[...]
>> There already is an effort to come up with a new AF_PACKET V4 [1].
>> We should make sure that any new interface does not have the
>> Y2038/Y2106 issue. But, if a new version is being developed and
>> that subsumes all existing use cases, then the
On Mon, Nov 27, 2017 at 9:35 PM, Willem de Bruijn
wrote:
> On Mon, Nov 27, 2017 at 11:59 AM, Jiri Pirko wrote:
>> Mon, Nov 27, 2017 at 05:19:25PM CET, a...@arndb.de wrote:
>>>I tried to figure out what it would take to do a version 4 mmap packet
>>>socket interface to completely avoid the y2106 o
On Mon, Nov 27, 2017 at 11:59 AM, Jiri Pirko wrote:
> Mon, Nov 27, 2017 at 05:19:25PM CET, a...@arndb.de wrote:
>>I tried to figure out what it would take to do a version 4 mmap packet
>>socket interface to completely avoid the y2106 overflow problem. This is
>>what I came up with, reusing most of
Mon, Nov 27, 2017 at 05:19:25PM CET, a...@arndb.de wrote:
>I tried to figure out what it would take to do a version 4 mmap packet
>socket interface to completely avoid the y2106 overflow problem. This is
>what I came up with, reusing most of the v3 code, except for the parts
>where we access the ti
I tried to figure out what it would take to do a version 4 mmap packet
socket interface to completely avoid the y2106 overflow problem. This is
what I came up with, reusing most of the v3 code, except for the parts
where we access the timestamps.
For kselftest, I'm adding support for testing v4 in
