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 your ops table by
providing your own close method and fill in the rest of the table with
the now-exposed kqueue ops methods.
So you are suggesting to just make kqueue fileops public? This was my
first suggestion, and this was rejected by Roman Divacky (who was
supposed to check it in) as very ugly. I did this through the method
kqueue_ops(), not directly though.
So can we agree on way to be used here?
Way#1: struct fileops* kqueue_fileops() which is used as the base for
epoll fileops.
Way#2: make kqueueops public and use as a base for epoll.
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.
Whatever makes code more clear is better. I don't think I suggested to
turn C into anything.
Yuri
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
