Re: How to best overload the fileops ?

On Wed, Aug 21, 2013 at 05:30:05PM -0700, Yuri wrote:
> On 08/21/2013 17:10, Mateusz Guzik wrote:
> >Short answer is provide epollops with your own fo_close and the rest as
> >it is currently in kqueueops. All function are static, but this is not a
> >real problem since you have to modify kern_event.c anyway.
> 
> This is exactly what this code I am asking about is doing.

I somehow missed your first mail and reponsed only to your reply to jmg,
sorry!

> kqueueops functions are all static. This modification allows to
> export fileops to child modules.
> Since there is nothing similar in the kernel code, I am asking does
> this way look ugly or not.
> 

I don't think there is a need to provide anything like this right now,
nor I have any good idea how to implement it.

> >
> >I don't know how your code looks like in general, so in case its not
> >clear, simply wrapping sys_kqueue is inherently racy (some other thread
> >may close the fd or even reuse it for something else by the time you try
> >to do anything with it), thus modification of current code is
> >unavoidable.
> 
> No, sys_kqueue calling code is all protected by the lock on this
> file object. So nobody can close or reuse it.
> 

I don't follow.

sys_kqueue creates fp on its own, before that there is nothing to lock
in the first place. By the time it returns, created fp can be long gone
because some other thread closed it.

FreeBSD idiom of dealing with that is creating fp with 2 refs and
dropping one when initialization is finished. That way close() from
userland does not kill fp until the code creating the object finishes.

Just my $0,03.
-- 
Mateusz Guzik <mjguzik gmail.com>