Date: Sun, 12 Sep 2004 04:44:02 -0700 From: Luigi Rizzo <rizzo@icir.org> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sbin/ipfw ipfw2.c Message-ID: <20040912044402.B48362@xorpc.icir.org> In-Reply-To: <20040911235359.GC72089@funkthat.com>; from gurney_j@resnet.uoregon.edu on Sat, Sep 11, 2004 at 04:53:59PM -0700 References: <200409111944.i8BJiTe7005412@repoman.freebsd.org> <20040911235359.GC72089@funkthat.com>
index | next in thread | previous in thread | raw e-mail
On Sat, Sep 11, 2004 at 04:53:59PM -0700, John-Mark Gurney wrote: > Christian S.J. Peron wrote this message on Sat, Sep 11, 2004 at 19:44 +0000: > > Currently when ipfw(8) generates the micro-instructions for rules which > > contain O_UID, O_GID and O_JAIL opcodes, the F_NOT or F_OR logical > > operator bits get clobbered. Making it impossible to use the ``NOT'' or > > ``OR'' operators with uid, gid and jail based constraints. > > > > The ipfw_insn instruction template contains a ``len'' element which > > stores two pieces of information, the size of the instruction > > (in 32-bit words) in the low 6 bits of "len" with the 2 remaining > > bits to implement OR and NOT. > > Why don't we use the bit field? > u_int8_t logic : 2; > u_int8_t len : 8; > > considering this is already used by the enum.. It'd make bugs like > these less likely... because the other field is 6 not 8, plus the alignment i think is compiler dependent and the generated code not often very fast, and this stuff is in the critical path in the kernel. cheers luigihome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040912044402.B48362>