From owner-freebsd-current@FreeBSD.ORG  Mon Aug 26 18:27:50 2013
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTP id 0C7AECBC;
 Mon, 26 Aug 2013 18:27:50 +0000 (UTC) (envelope-from jhb@freebsd.org)
Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1])
 (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits))
 (No client certificate requested)
 by mx1.freebsd.org (Postfix) with ESMTPS id CC2B6263D;
 Mon, 26 Aug 2013 18:27:49 +0000 (UTC)
Received: from jhbbsd.localnet (unknown [38.105.238.108])
 by bigwig.baldwin.cx (Postfix) with ESMTPSA id 87952B945;
 Mon, 26 Aug 2013 14:27:48 -0400 (EDT)
From: John Baldwin <jhb@freebsd.org>
To: Ian Lepore <ian@freebsd.org>
Subject: Re: How to best overload the fileops ?
Date: Mon, 26 Aug 2013 10:30:05 -0400
User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; )
References: <521508F4.6030502@rawbw.com> <5217C0DC.8050107@rawbw.com>
 <1377290165.1111.85.camel@revolution.hippie.lan>
In-Reply-To: <1377290165.1111.85.camel@revolution.hippie.lan>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201308261030.05683.jhb@freebsd.org>
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
 (bigwig.baldwin.cx); Mon, 26 Aug 2013 14:27:48 -0400 (EDT)
Cc: Yuri <yuri@rawbw.com>, John-Mark Gurney <jmg@funkthat.com>,
 Mateusz Guzik <mjguzik@gmail.com>, Roman Divacky <rdivacky@freebsd.org>,
 freebsd-current@freebsd.org
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
 <freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>, 
 <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
 <mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Aug 2013 18:27:50 -0000

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 Baldwin