Date: Fri, 23 Aug 2013 14:36:05 -0600 From: Ian Lepore <ian@FreeBSD.org> To: Yuri <yuri@rawbw.com> Cc: Mateusz Guzik <mjguzik@gmail.com>, current@FreeBSD.org, John-Mark Gurney <jmg@funkthat.com>, freebsd-current@FreeBSD.org, Roman Divacky <rdivacky@FreeBSD.org> Subject: Re: How to best overload the fileops ? Message-ID: <1377290165.1111.85.camel@revolution.hippie.lan> In-Reply-To: <5217C0DC.8050107@rawbw.com> References: <521508F4.6030502@rawbw.com> <20130822001022.GA18115@dft-labs.eu> <52155B8D.1020807@rawbw.com> <201308231302.32800.jhb@freebsd.org> <5217C0DC.8050107@rawbw.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1377290165.1111.85.camel>