Date: Mon, 26 Nov 2012 14:10:16 +0100 From: Andre Oppermann <andre@freebsd.org> To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= <eri@freebsd.org> Cc: Gleb Smirnoff <glebius@freebsd.org>, src-committers@freebsd.org, svn-src-user@freebsd.org Subject: Re: svn commit: r243458 - in user/andre/tcp_workqueue/sys: net netinet Message-ID: <50B36A38.7040603@freebsd.org> In-Reply-To: <CAPBZQG3cWBfgwXR_1Q%2BZjSOsE13PeOK12AjqFkgYay%2Bh-Xcpig@mail.gmail.com> References: <201211231453.qANErSKF034907@svn.freebsd.org> <20121123152741.GZ84121@FreeBSD.org> <CAPBZQG3cWBfgwXR_1Q%2BZjSOsE13PeOK12AjqFkgYay%2Bh-Xcpig@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23.11.2012 17:11, Ermal Luçi wrote: > On Fri, Nov 23, 2012 at 4:27 PM, Gleb Smirnoff <glebius@freebsd.org <mailto:glebius@freebsd.org>> wrote: > > Frankly speaking, the fact that the list can't be set directly > in one sysctl oid: > > sysctl net.inet.pfil_in.hooks="pf,ipfw,ipfilter" > > , but can only be set via suppling pointless numeric values to N > oids looks very poor from perspective of an average user. He might > think something like "oh, FreeBSD developers were too lazy to parse > a string", or "they designed an interface not for people but for nerds". > > Interface must be easier! If you don't like parsing strings in kernel, > then /sbin/pfilctl can be introduced. The utility eventually may grow > more functionality. > > I already gave a link to already existing patch for this. > Not sure why andre@ decided the other way around. I wanted to have a pre-determined default order of pfil modules especially with the IPSec pfil hook I've started working on. That's the reason for the ordering value. This ordering value has to be carried along somehow. Also I'm no fan of kernel side parsing, even if there are instances where it can't be avoided. So the default pfil hook ordering should lessen the need to reorder pfil hooks at runtime. Would you mind having a pfilctl at Gleb suggested? That way we could abstract the whole thing away and also gain flexibility in the kernel implementation for the future. Another question: In your patch you have a pfil hook disable option directly in the hook mechanism. What is the reason for that versus having the pfil consumer unhook itself when not enabled or in use? -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50B36A38.7040603>