On 2016/04/18 20:40, Martin Natano wrote:
> I have bumping bpf_timeval to 64bit on my todo list too. However I'm not
> sure what the best course of action is there. Replacing bpf_timeval with
> timeval might be problematic, because that means bpf wouldn't be binary
> stable across platforms. (tv_us
On Sat, Apr 16, 2016 at 11:10:14AM +0100, Stuart Henderson wrote:
> On 2016/04/15 23:07, Philip Guenther wrote:
> > On Thu, Apr 14, 2016 at 3:15 PM, Martin Natano wrote:
> > > In rbootd a struct bpf_timeval (with 32bit tv_sec) is copied to a struct
> > > timeval (with 64 tv_sec) via bcopy(). This
On Fri, 15 Apr 2016 23:07:47 -0700, Philip Guenther wrote:
> The current code is simply wrong: sizeof(struct timeval) >
> sizeof(struct bpf_timeval). I think we should make this change (ok
> guenther@) and then work to update struct bpf_hdr or a replacement
> thereof to not be limited to 32bit ti
On 2016/04/15 23:07, Philip Guenther wrote:
> On Thu, Apr 14, 2016 at 3:15 PM, Martin Natano wrote:
> > In rbootd a struct bpf_timeval (with 32bit tv_sec) is copied to a struct
> > timeval (with 64 tv_sec) via bcopy(). This most likely causes
> > connections to not time out correctly in rbootd. I
On Thu, Apr 14, 2016 at 3:15 PM, Martin Natano wrote:
> In rbootd a struct bpf_timeval (with 32bit tv_sec) is copied to a struct
> timeval (with 64 tv_sec) via bcopy(). This most likely causes
> connections to not time out correctly in rbootd. I don't have an HP
> machine to test this with. Who ow
In rbootd a struct bpf_timeval (with 32bit tv_sec) is copied to a struct
timeval (with 64 tv_sec) via bcopy(). This most likely causes
connections to not time out correctly in rbootd. I don't have an HP
machine to test this with. Who owns such a machine and is willing to
test this?
natano
Index:
