Re: How to best overload the fileops ?

> 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.

This kinda leave it hanging in the same state.

To do this kqueue fileops need to be exposed. It is always possible to 
create something like "struct fileops* kqueue_fileops()" and that would 
do it.
I just tried to make such exposure as nice as I could, using some 
accepted paradigms (overloading, etc) and macros that look like some IDE 
might create.
Another approach is to read fileops from file after the first call to 
sys_kqueue, but I dislike this because this would require an additional 
lock, also this would make the first call to epoll_create different from 
the others, which it shouldn't be. Also this would look much more like a 
hack.

What is wrong with the suggested approach anyway?

>> >
>> >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.

I added the method kqueue_locked that leaves the the lock release to the 
calling routine (another kernel module). This way both epoll_create and 
sys_kqueue run under one atomic lock.

Yuri