Date: Wed, 21 Aug 2013 19:06:24 -0700 From: Yuri <yuri@rawbw.com> To: Mateusz Guzik <mjguzik@gmail.com> Cc: John-Mark Gurney <jmg@funkthat.com>, Roman Divacky <rdivacky@freebsd.org>, current@freebsd.org Subject: Re: How to best overload the fileops ? Message-ID: <52157220.8030400@rawbw.com> In-Reply-To: <20130822012011.GA11987@dft-labs.eu> References: <521508F4.6030502@rawbw.com> <20130821232113.GD94127@funkthat.com> <521552E2.2000008@rawbw.com> <20130822001022.GA18115@dft-labs.eu> <52155B8D.1020807@rawbw.com> <20130822012011.GA11987@dft-labs.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52157220.8030400>