Date: Wed, 6 Oct 2004 01:00:23 +0200 From: Max Laier <max@love2party.net> To: Brian Fundakowski Feldman <green@freebsd.org> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/contrib/pf/man pf.4 Message-ID: <200410060100.47991.max@love2party.net> In-Reply-To: <20041005212704.GB47017@green.homeunix.org> References: <200410052044.i95KiOVV072560@repoman.freebsd.org> <20041005212704.GB47017@green.homeunix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Tuesday 05 October 2004 23:27, Brian Fundakowski Feldman wrote: > On Tue, Oct 05, 2004 at 08:44:24PM +0000, Max Laier wrote: > > mlaier 2004-10-05 20:44:24 UTC > > > > FreeBSD src repository > > > > Modified files: (Branch: RELENG_5) > > contrib/pf/man pf.4 > > Log: > > MFC: > > PFIL_HOOKS in no longer an optional item. > > > > Submitted by: Anders Hanssen > > I have a bunch of questions regarding pf documentation... > > Do you think we should update pf(4)/pfctl(8) documentation to > cross-reference IPFW at all? I fail to see that point, but I don't care much either way. Maybe I should add pf to the firewall(7) "ADDITIONAL READING"? > Is it worth explaining in pfctl(8) what the default RED parameters for > ALTQ are and how they relate to qlimit? Sure. pf.conf(5), right? That's the place you were thinking of - not pfctl(8)? > Isn't there an altq.4 somewhere? No. Feel free to write it. I agree that ALTQ documentation is suboptimal at the moment. I had plans to evolve the configuration process, but didn't yet find time to ... in the longrun it should no longer require dev/pf and all that ... > Shouldn't pfctl(8) document what occurs when there is no memory to add > an ALTQ tag? pf.conf(5)? Well, if you don't have memory for a tag you are in trouble anyway. But what happens? The packet ends up in the default queue (I hope). > P.S. Think we should MFC dc(4) ALTQ support? You know if it works or not, can't comment on that. If it does work, go for it. Make sure to update altq(8) as well (or the TBD altq(4)) > P.P.S. Should we look again into changing the pfil locking to not > fail-open? Feel free to make if fail-close. You must not sleep there, so it's either open or close. In contrast to what I told you earlier - you can return EAGAIN or ENOBUF so that applications don't get confused. Other than that, I am still waiting for you to commit sxfast so that I can redo the pfil locking with it. I am wondering, however, if you didn't try to sleep there as well (which is not possible here). -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBYyefXyyEoT62BG0RAj0wAJ0YVgVcXqwaysfcVCOUkXzu20HFpQCdGCy3 bc+9ehS8L8C6tng0fv7mEXI= =whrN -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200410060100.47991.max>