From owner-freebsd-current@FreeBSD.ORG  Fri Aug 23 22:18:41 2013
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTP id D888221A;
 Fri, 23 Aug 2013 22:18:41 +0000 (UTC) (envelope-from yuri@rawbw.com)
Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45])
 by mx1.freebsd.org (Postfix) with ESMTP id BE308281C;
 Fri, 23 Aug 2013 22:18:41 +0000 (UTC)
Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1])
 (authenticated bits=0)
 by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r7NMIe29057242;
 Fri, 23 Aug 2013 15:18:40 -0700 (PDT) (envelope-from yuri@rawbw.com)
Message-ID: <5217DFC0.7070708@rawbw.com>
Date: Fri, 23 Aug 2013 15:18:40 -0700
From: Yuri <yuri@rawbw.com>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
 rv:17.0) Gecko/20130822 Thunderbird/17.0.8
MIME-Version: 1.0
To: Ian Lepore <ian@freebsd.org>
Subject: Re: How to best overload the fileops ?
References: <521508F4.6030502@rawbw.com> <20130822001022.GA18115@dft-labs.eu>
 <52155B8D.1020807@rawbw.com> <201308231302.32800.jhb@freebsd.org>
 <5217C0DC.8050107@rawbw.com> <1377290165.1111.85.camel@revolution.hippie.lan>
In-Reply-To: <1377290165.1111.85.camel@revolution.hippie.lan>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: John-Mark Gurney <jmg@funkthat.com>, Mateusz Guzik <mjguzik@gmail.com>,
 current@freebsd.org, 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: Fri, 23 Aug 2013 22:18:41 -0000

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