On 15 April 2015 at 13:29, kanonenvogel@gmail.com
kanonenvogel@gmail.com wrote:
On 14 Apr 2015, at 18:35, Mike Belopuhov m...@belopuhov.com wrote:
Supposedly you don't have to KERNEL_LOCK for pool_{get,put} anymore.
Underlying uvm calls are not mp safe
True.
and not protected by
On 15 Apr 2015, at 19:45, Mike Belopuhov m...@belopuhov.com wrote:
On 15 April 2015 at 13:29, kanonenvogel@gmail.com
kanonenvogel@gmail.com wrote:
On 14 Apr 2015, at 18:35, Mike Belopuhov m...@belopuhov.com wrote:
Supposedly you don't have to KERNEL_LOCK for pool_{get,put}
On 14 Apr 2015, at 18:35, Mike Belopuhov m...@belopuhov.com wrote:
Supposedly you don't have to KERNEL_LOCK for pool_{get,put} anymore.
Underlying uvm calls are not mp safe and not protected by KERNEL_LOCK() calls.
On 14 April 2015 at 17:19, kanonenvogel@gmail.com
kanonenvogel@gmail.com wrote:
Ok, I split my huge patch to some small. f_flag and f_iflags are not affected
by this patch set,
because they are under mp lock this time.
And just for lulz, I made sys_pipe, sys_pipe2 syscalls and
On 12 Apr 2015, at 21:02, Martin Pieuchot m...@openbsd.org wrote:
It's only PoF just for to show my hypothetical roadmap.
Can you explain what need to be protected from what?
1. Filelist, nfiles and operations with them are protected by rwlock.
Why not, could you describe why they need a
This is the second attempt of struct file protection.
1. Filelist, nfiles and operations with them are protected by rwlock.
2. Garbage collector's flags FIF_MARK and FIF_DEFER moved from f_iflags to
new field f_gc_flags (compatibility with pstat was kept).
3. Operations over f_iflags are atomic.
Hello,
This is an interesting diff with a lot of stuff in it. I'd suggest
you to give more details about what you're trying to achieve with it
and split it into small parts.
It's nice to see some work done in this area, but do not rush you'd be
surprise by the dragons in there.
On
