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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040912044402.B48362>