User Details
- User Since
- Jun 5 2014, 2:54 AM (547 w, 3 d)
May 5 2016
Apr 30 2016
LGTM. Colin?
Jan 5 2016
looks good to me (in principle), and I like this approach. I'm not build system savvy so I'd like dim to sign-off this one.
Nov 30 2015
The changes look good. I'd split them in multiple patches/commit, more or less following the structure you outlined in the summary, but thanks for sending out a single one so we can have the whole picture.
IIRC there were objections to change ticks from 32-bits to 64-bits so you may want to ask feedback from a more general audience.
Other than that, I'm fine with (a splitted version of this) getting in.
May 19 2015
Sounds sensible.
May 13 2015
Can't comment on license issues and related tho.
LGTM. Feel free to ship (maybe John wants to comment further as he's been touching gdb recently)
May 8 2015
The patch looks very good to me and thanks for undertaking this effort.
About SDT I don't disagree with them but *exclusively* seems a little bit too much, lots of people rely on KTR for tracing (me included) and it seems to be a more lighweight solution than Dtrace if you need limited capabilities.
Feb 14 2015
In HEAD now.
Feb 11 2015
Robert,
an added (somewhat related) note.
SCTP has already its own sockbuf(s) and this makes integration very hackish in the tree. IIRC glebius experienced this himself while working on sendfile(), and I'm pretty sure rrs@ is kind of familiar with the problem. Introducing a better abstraction for sockbuf might help with this.
Mainly for consistency at this point with whatever else it's used in the stack.
I plan to commit this in two days or such, so if there are objections, please raise them.
I plan to commit this in two days or such, so if there are objections, please raise them.
Feb 9 2015
Updated removing the last place where this was used. I was not certain about it before so I previously left it as-is, but it looks like in this case order doesn't matter considering we're holding the socket buffer lock across the two calls.
Feb 8 2015
Nov 27 2014
Drop this revision after discussion on the mailing list.
Abandoned in favour of a different approach
Nov 14 2014
This looks good to me modulo mav's last round of comments.
Oct 21 2014
LGTM
Oct 17 2014
unsetenv is not used anywhere in the kernel -- just in the loader. As you may see the loader code was unchanged.
Do you have an alternative to handle the whole thing in your mind?
Aug 20 2014
Committed (r270221)
bde@ accepted this revision privately.
Bruce Evans reviewed this privately.
Let's copy his comment here:
Aug 12 2014
Updated after comments from Kostik/Robert.
Peter, do you mind to give this a spin before it gets in? I tested that a bit and found no issue -- but it would be great if the patch could be stress tested a bit more.