From owner-svn-src-projects@FreeBSD.ORG Thu Oct 9 16:19:17 2014 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7CFFE2EE; Thu, 9 Oct 2014 16:19:17 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2CD1E6A2; Thu, 9 Oct 2014 16:19:17 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XcCRL-000Pc2-K3; Thu, 09 Oct 2014 16:03:27 +0400 Message-ID: <5436B52E.3010106@FreeBSD.org> Date: Thu, 09 Oct 2014 20:17:50 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: John Baldwin Subject: Re: svn commit: r272515 - projects/ipfw/sys/netpfil/ipfw References: <201410041210.s94CAX7I012628@svn.freebsd.org> <5520708.eFNh9vYom7@ralph.baldwin.cx> In-Reply-To: <5520708.eFNh9vYom7@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-projects@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 16:19:17 -0000 On 06.10.2014 19:45, John Baldwin wrote: > On Saturday, October 04, 2014 12:10:33 PM Alexander V. Chernikov wrote: >> Author: melifaro >> Date: Sat Oct 4 12:10:32 2014 >> New Revision: 272515 >> URL: https://svnweb.freebsd.org/changeset/base/272515 >> >> Log: >> Add "ipfw_ctl3" FEATURE to indicate presence of new ipfw interface. >> >> Modified: >> projects/ipfw/sys/netpfil/ipfw/ip_fw2.c >> >> Modified: projects/ipfw/sys/netpfil/ipfw/ip_fw2.c >> ============================================================================ >> == --- projects/ipfw/sys/netpfil/ipfw/ip_fw2.c Sat Oct 4 11:40:35 >> 2014 (r272514) +++ projects/ipfw/sys/netpfil/ipfw/ip_fw2.c Sat Oct 4 >> 12:10:32 2014 (r272515) @@ -2874,6 +2874,7 @@ static moduledata_t ipfwmod = >> { >> #define IPFW_VNET_ORDER (IPFW_MODEVENT_ORDER + 2) /* Later still. */ >> >> DECLARE_MODULE(ipfw, ipfwmod, IPFW_SI_SUB_FIREWALL, IPFW_MODEVENT_ORDER); >> +FEATURE(ipfw_ctl3, "ipfw new sockopt calls"); >> MODULE_VERSION(ipfw, 2); >> /* should declare some dependencies here */ > Would it be better to bump the module version to 3 instead? Userland programs > can then use modfind() and modstat() to determine the version. I've bumped ipfw module version in r272828. Actually, I've entirely forgotten about this possibility. However, it is a bit hard to determine module version inside (perl|python|sh|any) script. On the other case, FEATURE framework provides nice and easy way to determine any "feature" status both in C and interpreted programs. >