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. -- Ian > > > > I don't think we need a generic framework for this, just expose the > > relevant fo_ methods for kqueue ops and use them in your epoll_ops. > > In epoll case, fileops object as a whole should be exposed and used for > fp->f_ops, except fo_close which is overloaded. > > So would you think struct fileops* kqueue_fileops(); be ok then? > > Yuri > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"Received on Fri Aug 23 2013 - 18:36:16 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:40 UTC