Date: Sat, 1 Apr 2006 21:04:04 -0600 From: Dan Nelson <dnelson@allantgroup.com> To: =?utf-8?Q?V=C3=A1clav?= Haisman <V.Haisman@sh.cvut.cz> Cc: hackers@freebsd.org Subject: Re: kqueue oddity Message-ID: <20060402030404.GB83967@dan.emsphone.com> In-Reply-To: <442EC7F7.3000608@sh.cvut.cz> References: <442E9354.5010700@sh.cvut.cz> <20060401180311.GA83967@dan.emsphone.com> <442EC7F7.3000608@sh.cvut.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Apr 01), Vclav Haisman said: > Dan Nelson wrote: > > It's a kqueue bug, but a minor one. The problem is that the same > > "flags" field is used to pass "actions" from the client, and return > > status from the kernel. When you call kqueue with EV_ADD, the > > kernel never clears the flags when creating the internal object, so > > it's always visible when events fire. This can get annoying when > > trussing kqueue-using programs because very single event has the > > EV_ADD flag :) Apply the following diff to have the kernel strip > > EV_ADD: > > Thanks. Why isn't this fix applied? From the patch's time stamp it > seems like it is known for quite some time now. Mainly because it's a cosmetic thing; most of the time you're not printing the raw kevent values. I never submitted a PR because it only gets annoying if my truss PR ( http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/52190 ) is committed, so it's waiting for that. EV_DISABLE needs the same treatment; my full kevent debugging patch is at http://www.allantgroup.com/FreeBSD/kevent.diff . -- Dan Nelson dnelson@allantgroup.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060402030404.GB83967>