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 how > > is this similar to our situation. devfs doesn't overload any other file > > system, they are a file system on their own. > > > > 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 your ops table by > providing your own close method and fill in the rest of the table with > the now-exposed kqueue ops methods. > > It's not as neat and clean as "class epollops : public kqueueops {...}" > but it's probably not as bad as using clever macros to try to turn C > into a sort of C++Lite. Correct. Just use something like: static struct fileops epollops = { .fo_read = kqueue_read, ... .fo_close = epoll_close, ... } -- John BaldwinReceived on Mon Aug 26 2013 - 16:27:50 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:40 UTC