- User Since
- May 16 2014, 7:35 PM (301 w, 3 d)
Yes, but why is it useful even slightly to prevent modifications to (successfull) result of the vn_fullpathX() ?
Sun, Feb 23
I really do not understand it. The *retbuf *is* modified by vn_fullpath. I believe you are lying to the compiler' aliasing analysis this way.
Sat, Feb 22
I would be slightly less worried about this hack if you added asserts that odevvp does not get any buffers on its bufobj queues.
Fri, Feb 21
Overall this looks reasonable.
I very much dislike this. It repeats the mistake of KASSERT() while not eliminating KASSERT.
Thu, Feb 20
Ok, lets postpone AT_NOFOLLOW.
Wed, Feb 19
Tue, Feb 18
How jails and chroots are handled ?
Mon, Feb 17
Biggest objection is that there is still no ABI for atomic stuff even on x86, so each compiler (version) is free to choose the implementation that it finds suitable and that non necessary compatible with the other' compiler implementation.
Sun, Feb 16
One setpend() was missed after refactoring.
re-upload with context.
Apply full pack of nano-optimizations, change sigfastblock_fetch_always to bool.
If one day I feel offended enough by this breakage, it seems that ptracestop() can be used to restore the functionality.
Sat, Feb 15
Why ? This is exactly how options work, at least for the coherent build of kernel and modules.
If module is buildable, I do not see a reason to not include it into the build. Mark can provide more input on this issue.
Another approach, summary will be updated.
Fri, Feb 14
It was a test for r357894. The victim thread exiting, then I need to wait for it to exit but not join, to issue cancellation request.
Ok, consider it from the following angle: does doing the sweep for CTLTYPE_NODE->CTLTYPE_PROC improves the code or just allows to avoid adding a flag, and then removing it ?