From owner-svn-src-projects@FreeBSD.ORG Mon Oct 13 15:16:21 2014
Return-Path: <owner-svn-src-projects@FreeBSD.ORG>
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 D15EFA67;
Mon, 13 Oct 2014 15:16:21 +0000 (UTC)
Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1])
(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
(Client did not present a certificate)
by mx1.freebsd.org (Postfix) with ESMTPS id A85CF8E;
Mon, 13 Oct 2014 15:16:21 +0000 (UTC)
Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net
[173.70.85.31])
by bigwig.baldwin.cx (Postfix) with ESMTPSA id B1E90B917;
Mon, 13 Oct 2014 11:16:20 -0400 (EDT)
From: John Baldwin <jhb@freebsd.org>
To: "Alexander V. Chernikov" <melifaro@ipfw.ru>
Subject: Re: svn commit: r272515 - projects/ipfw/sys/netpfil/ipfw
Date: Mon, 13 Oct 2014 09:46:28 -0400
Message-ID: <2638508.DdhyVaDRpY@ralph.baldwin.cx>
User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; )
In-Reply-To: <AC6B3AB3-30C2-44BC-933F-A37F14F01C90@ipfw.ru>
References: <201410041210.s94CAX7I012628@svn.freebsd.org>
<201410091711.28587.jhb@freebsd.org>
<AC6B3AB3-30C2-44BC-933F-A37F14F01C90@ipfw.ru>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7
(bigwig.baldwin.cx); Mon, 13 Oct 2014 11:16:20 -0400 (EDT)
Cc: svn-src-projects@freebsd.org, src-committers@freebsd.org,
"Alexander V. Chernikov" <melifaro@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" <svn-src-projects.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/svn-src-projects>,
<mailto:svn-src-projects-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/svn-src-projects/>
List-Post: <mailto:svn-src-projects@freebsd.org>
List-Help: <mailto:svn-src-projects-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-projects>,
<mailto:svn-src-projects-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Oct 2014 15:16:22 -0000
On Sunday, October 12, 2014 12:13:00 AM Alexander V. Chernikov wrote:
> On 10 Oct 2014, at 01:11, John Baldwin <jhb@freebsd.org> wrote:
> > On Thursday, October 09, 2014 12:17:50 pm Alexander V. Chernikov wr=
ote:
> >> 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
> >>>>=20
> >>>> Log:
> >>>> Add "ipfw_ctl3" FEATURE to indicate presence of new ipfw inter=
face.
> >>>>=20
> >>>> Modified:
> >>>> projects/ipfw/sys/netpfil/ipfw/ip_fw2.c
> >>>>=20
> >>>> Modified: projects/ipfw/sys/netpfil/ipfw/ip_fw2.c
> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
> >>>> =3D=3D=3D=3D=3D =3D=3D --- projects/ipfw/sys/netpfil/ipfw/ip_fw2=
.c=09Sat Oct 4
> >>>> 11:40:35 2014=09(r272514) +++
> >>>> projects/ipfw/sys/netpfil/ipfw/ip_fw2.c=09Sat Oct 4 12:10:32
> >>>> 2014=09(r272515) @@ -2874,6 +2874,7 @@ static moduledata_t ipfwm=
od =3D {
> >>>>=20
> >>>> #define=09IPFW_VNET_ORDER=09=09(IPFW_MODEVENT_ORDER + 2) /* Lat=
er still.=20
*/
> >>>> =20
> >>>> DECLARE_MODULE(ipfw, ipfwmod, IPFW_SI_SUB_FIREWALL,
> >>>> IPFW_MODEVENT_ORDER);
> >>>>=20
> >>>> +FEATURE(ipfw_ctl3, "ipfw new sockopt calls");
> >>>>=20
> >>>> MODULE_VERSION(ipfw, 2);
> >>>> /* should declare some dependencies here */
> >>>=20
> >>> Would it be better to bump the module version to 3 instead? User=
land
> >>> programs can then use modfind() and modstat() to determine the ve=
rsion.
> >>=20
> >> I've bumped ipfw module version in r272828. Actually, I've entirel=
y
> >> 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.
> >=20
> > I'll grant you that feature is convenient. Perhaps create a SYSCTL=
node
> > though that holds the current version? That is 'foo.ipfw.version' =
being
> > 2 or 3 is more future proof than 'feature.ipfw2/3/4=E2=80=99.
>=20
> No, this is not about new _ipfw_ version. I=E2=80=99m unsure if all t=
hese changes
> are large enough to name ipfw as =E2=80=9Cipfw3=E2=80=9D. This is jus=
t an indication that
> all ipfw-related sockopts are available via single setsockopt called
> IP_FW3. Maybe naming is not the best - I=E2=80=99m open to any sugges=
tion.
Hmm, it sure seems like a new version in that there is a different styl=
e of=20
interface similar to how umtx changed from discrete system calls=20
(umtx_lock/unlock) to a multiplexer (umtx_op).
> However, I=E2=80=99m not sure why should I invent additional sysctls =
instead of
> using standard interface.
Well, I think using FEATURE() to communicate version numbers is not rea=
lly
its intended application. That said, if you wanted, another option wou=
ld be
to possibly rename the socket options to something like 'IP_FW_OP' and
'IP_DUMMYNET_OP' (to reflect that they take an operation as an argument=
similar to umtx_op). Also, if what you care about is 'xtable' support,=
you
could have 'FEATURE(ipfw_xtable)'. That is more along the lines of how=
FEATURE() is currently used rather than version numbers.
> > Alternatively, we could change the module code to export a dynamic =
sysctl
> > tree for all loaded modules that includes the versions, i.e.
> > 'module.<foo>.version', etc.
This is still another idea that would transparently export MODULE_VERSI=
ON()
info via sysctls without requiring API changes.
--=20
John Baldwin