On Friday, August 23, 2013 6:18:40 pm Yuri wrote:
On 08/23/2013 13:36, Ian Lepore wrote:
I think the point is that devfs_ops_f provides several devfs-specific
methods and then inherits the rest by referencing the standard
vn_whatever functions. Since John recommended that you expose the
On Friday, August 23, 2013 4:36:05 pm Ian Lepore wrote:
On Fri, 2013-08-23 at 13:06 -0700, Yuri wrote:
On 08/23/2013 10:02, John Baldwin wrote:
There is something similar: see devfs_ops_f in
sys/fs/devfs/devfs_vnops.c.
devfs_ops_f is a local static fileops object for devfs. I don't see
On Wednesday, August 21, 2013 8:30:05 pm 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
On 08/23/2013 10:02, John Baldwin wrote:
There is something similar: see devfs_ops_f in sys/fs/devfs/devfs_vnops.c.
devfs_ops_f is a local static fileops object for devfs. I don't see how
is this similar to our situation. devfs doesn't overload any other file
system, they are a file system
On Fri, 2013-08-23 at 13:06 -0700, Yuri wrote:
On 08/23/2013 10:02, John Baldwin wrote:
There is something similar: see devfs_ops_f in sys/fs/devfs/devfs_vnops.c.
devfs_ops_f is a local static fileops object for devfs. I don't see how
is this similar to our situation. devfs doesn't
On 08/23/2013 13:36, Ian Lepore wrote:
I think the point is that devfs_ops_f provides several devfs-specific
methods and then inherits the rest by referencing the standard
vn_whatever functions. Since John recommended that you expose the
fo_whatever methods, I think he's suggesting you build
I am working on linux epoll functionality for linuxlator. It implements
epoll through kqueue, but there is the need to overload fo_close
function in fileops to free some memory.
There is no generic mechanism defined in the kernel sources allowing to
do this, and it isn't desirable to do this
Yuri wrote this message on Wed, Aug 21, 2013 at 11:37 -0700:
I am working on linux epoll functionality for linuxlator. It implements
epoll through kqueue, but there is the need to overload fo_close
function in fileops to free some memory.
How did this memory get allocated in the first place?
On 08/21/2013 16:21, John-Mark Gurney wrote:
How did this memory get allocated in the first place? Why does it need
to be free'd in fo_close and not another location?
It is allocated by the epoll module right after kqueue object is created
and is attached to the opaque field in the file
On Wed, Aug 21, 2013 at 04:53:06PM -0700, Yuri wrote:
On 08/21/2013 16:21, John-Mark Gurney wrote:
How did this memory get allocated in the first place? Why does it need
to be free'd in fo_close and not another location?
It is allocated by the epoll module right after kqueue object is
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
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
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()
13 matches
Mail list logo
