> On 21 Jan 2015, at 5:50 am, Simon Mages wrote:
>
> Sorry, i did not test the Patch well enough.
>
> It is still broken, but in a different way.
>
> I think tedu forgot in his patch to reset d->bd_rdStart. From my point
> of view it
> should be zero after sleeping in this case. Because if you
Is everything right with my regression test?
2015-01-21 15:28 GMT+01:00, Simon Mages :
> btw. here is my regression test for bpf:
>
> Index: regress/sys/net/Makefile
> ===
> RCS file: /home/cvs/src/regress/sys/net/Makefile,v
> retriev
btw. here is my regression test for bpf:
Index: regress/sys/net/Makefile
===
RCS file: /home/cvs/src/regress/sys/net/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- regress/sys/net/Makefile12 Jul 2014 21:41:49 -00
Sorry, i did not test the Patch well enough.
It is still broken, but in a different way.
I think tedu forgot in his patch to reset d->bd_rdStart. From my point
of view it
should be zero after sleeping in this case. Because if you read again after a
successful read the timeout wont be processed be
I tested the patch and its working.
I have a small test program already. I create a regression test with it.
I'll post the diff here.
Am 06.01.2015 04:19 schrieb "Philip Guenther" :
> [(@#*$&(*# control-enter keybinding]
>
> On Mon, Jan 5, 2015 at 7:15 PM, Philip Guenther
> wrote:
> > On Mon, J
[(@#*$&(*# control-enter keybinding]
On Mon, Jan 5, 2015 at 7:15 PM, Philip Guenther wrote:
> On Mon, Jan 5, 2015 at 11:01 AM, Ted Unangst wrote:
> ...
>> In the regular timeout case, I'm not sure what you're changing. There
>> is a problem here though. If we're already close to the timeout
>> e
On Mon, Jan 5, 2015 at 11:01 AM, Ted Unangst wrote:
...
> In the regular timeout case, I'm not sure what you're changing. There
> is a problem here though. If we're already close to the timeout
> expiring, we shouldn't sleep the full timeout, only the time left
> since we began the read.
>
> Loo
On Sun, Jan 04, 2015 at 21:06, Mages Simon wrote:
> I restored the functionality according to the manpage.
>
> That means that read() on bpf is blocking again. If a
> timeout is set read() will block until the timeout is
> over.
>
> Maybe asynchronous is also broken, i will look into that later.
I restored the functionality according to the manpage.
That means that read() on bpf is blocking again. If a
timeout is set read() will block until the timeout is
over.
Maybe asynchronous is also broken, i will look into that later.
Index: sys/net/bpf.c
==
