From owner-freebsd-arch@FreeBSD.ORG Sat Apr 5 15:36:34 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BEEF7B54; Sat, 5 Apr 2014 15:36:34 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 464C8DCC; Sat, 5 Apr 2014 15:36:34 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s35FaLMd055575; Sat, 5 Apr 2014 18:36:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s35FaLMd055575 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s35FaLdI055574; Sat, 5 Apr 2014 18:36:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 5 Apr 2014 18:36:21 +0300 From: Konstantin Belousov To: Ed Schouten Subject: Re: [Patch] kqueue(2) <-> procdesc(4): EVFILT_PROCDESC Message-ID: <20140405153621.GH21331@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="11IAkegDWp8TRrA/" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Robert Watson , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 15:36:34 -0000 --11IAkegDWp8TRrA/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 05, 2014 at 12:00:43PM +0200, Ed Schouten wrote: > Hi Robert, >=20 > The other day I was playing around with procdesc(4). Quite a nice > piece of work. I did notice, though, that there is no way you can use > kqueue(2) to monitor process descriptors. That's quite a shame, > because it would be awesome if we could just use EVFILT_PROC on > process descriptors directly. This is why I thought it would be nice > to introduce a variant called EVFILT_PROCDESC. >=20 > I initially tried altering kqueue(2) in such a way that > EVFILT_PROCDESC would use a mixture of filt_fileattach() to attach to > the descriptor and filt_proc() to watch for events, but this approach > didn't really work out all that well, for the reason that a kevent > either has a file descriptor or a process associated; not both. >=20 > In the end I decided to not make things more complex than needed and > just implement it like a regular file descriptor probe. This means > that we can get NOTE_EXIT to work, but NOTE_FORK, NOTE_EXEC and > NOTE_TRACK would require some more work. >=20 > What are your thoughts on the following patch? >=20 > http://80386.nl/pub/kqueue-evfilt-procdesc.txt >=20 > Some notes on this patch: >=20 > - I decided to just reuse the obsolete EVFILT_NETDEV. EVFILT_PROCDESC > will be used on completely different file descriptor types, so I can't > think of a way this would cause ABI issues. >=20 > - pd->pd_proc is protected by proctree_lock. It's a bit hard to pick > this up inside of the kqfilter, so simply make procdesc_exit() copy > out pd->pd_proc->p_xstat. We also want this copy, because we don't > want to run into a race condition where wait4() already reaps the > process before the kqfilter is called. This is works for EVFILT_PROC > anyway. >=20 > The nice thing about this patch is that even though pdwait4(2) is > still unimplemented, it does at least allow people to now extract the > exit code without accessing any global namespaces. procdesc_kqops_event() should mimic the filt_proc() much more closely than you do. In particular: - I do not see why do you check for NOTE_EXIT in kqops_event(). If enforcing NOTE_EXIT anywhere, procdesc_kqfilter() is more natural place to put the temporal restriction. I do think that signalling and execing are equally useful as exiting notifications, but this is for future. - The whole structure of filt_proc(), which copies masked sfflags to fflags is easier to extend later. It seems that just repeating most of the code from filt_proc() would do what needed.=20 I think you must do knlist_clear() before knlist_destroy(). --11IAkegDWp8TRrA/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTQCL1AAoJEJDCuSvBvK1BLVYQAKfTXhLBPY7bAzGacGlUJLu8 uG/GrCsEryr49oFw6C73g6y0JYGW7kcWGYyknQ3Iz0/52c5c8DzIj2q5gSvrG0Ih RpgdrDYRMiVRcoQzoQxmT2pJ9e2LzNnk6Hnz6zWwOgBlkz9EYVs44s0LLOlbCzEx 0+uEYMr6ACOspE421/y4c4H8jB1EZ6VMvxjONWqVzZpHR5xzxzFtZ73/JAKrCwt9 DANQqHImXykhTqsomv4edeJ0e/TJRykHP2HqojYsRqSlE2boneJGrsoDX18BqKwi H6KqNMpgYOx+4cngsxhKJznIoOVSfmp0gvILZgLn6ySatn1cTKfle9lum0PHEHqZ o5bl8GTVmEqols9q14CzxXbGNg/FW2WBobb7iQUNK1TIyBE+wwMZl3ArN8jSg8LS rjTs2lp65O+ZU0+/yex2MVaX2DwCyX+iN1Li0E5P8Z/0D26txc3TNGyxUm31e+w6 wV4szGVy8a0l5oz9CplVfkjGYfGEKIZ5qz0PK+PwODxsP0r2wqmbZnd4XaUAPNpP 4r03lqqO0It8QdYo0u3or6luGKHB6EV99xy3M9CLvI9dPyaVXkNAq7KF1xp0gvhB bOaVYhWFb0zoe+/HN/GCJCFTvzfKeDdgbyggV/IswdmVnS8CdLtmc4jo/sarcVD0 hyfmf3LOPdURY7lxjxFT =fPku -----END PGP SIGNATURE----- --11IAkegDWp8TRrA/--