From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 21 08:26:10 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2F56106564A; Sat, 21 Jan 2012 08:26:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 9C9B68FC13; Sat, 21 Jan 2012 08:26:09 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q0L8Q5f7032222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Jan 2012 10:26:05 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q0L8Q5eU003788; Sat, 21 Jan 2012 10:26:05 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q0L8Q4KV003787; Sat, 21 Jan 2012 10:26:04 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 21 Jan 2012 10:26:04 +0200 From: Kostik Belousov To: Eitan Adler Message-ID: <20120121082604.GT31224@deviant.kiev.zoral.com.ua> References: <20120112100840.GV31224@deviant.kiev.zoral.com.ua> <20120120235645.GP31224@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5kuBRoVe25Cd17OM" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: jilles@freebsd.org, FreeBSD Hackers , Colin Percival Subject: Re: dup3 syscall - atomic set O_CLOEXEC with dup2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 08:26:10 -0000 --5kuBRoVe25Cd17OM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 20, 2012 at 07:09:43PM -0500, Eitan Adler wrote: > 2012/1/20 Kostik Belousov : > > On Fri, Jan 20, 2012 at 06:25:42PM -0500, Eitan Adler wrote: > >> I figure this isn't wanted? > > You silently ignored part of the notes that were provided, >=20 > I fixed the style violations you pointed out and removed > _SYS_SYSPROTO_H_ and friends. Which else was there? If I missed > something I'm sorry. Manual definition of the struct dup3_args is not needed at all. I very much doubt that patch can compile since there is now duplicate definition of the structure. There is still stray return (0);. Another reason for the patch to not compile is compat32 syscalls.master changes. The suggestion of 'it is better to test the presence of O_CLOEXEC with & instead of comparing with =3D=3D, to allow for ease introduction of future dup3 flags, if any.' is silently ignored. Probably new: style requires putting opening '{' for the function body at new line. There shall be no space between '*' and arg name. New: symbols in the version map shall be ordered alphabetically. >=20 > > and keep > > complete silence on the primary question about non-standard >=20 > I thought I answered that already but I'll try again: I believe the > functionality is useful to developers even if it is non-standard. In > addition if it is standardized at some point in the future it is > unlikely to have different semantics than the ones implemented. It very well may have different details that would force us to draw two versions forever. >=20 > > and fractional nature of the patch. >=20 > How so? I am not including the generated parts in the patch. Should I? The implementation is partial because dup3() is only part of the Linux and glibc efforts to allow app authors to handle the race between obtaining the file descriptor and setting cloexec flag. I already pointed you to SOCK_CLOEXEC for example. This is ignored as well. dup3() alone is almost useless. >=20 > > I see no reason to retype my previous response. >=20 > --=20 > Eitan Adler --5kuBRoVe25Cd17OM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk8adpwACgkQC3+MBN1Mb4g5lgCdFU821OXnlHodGC4Vfx0OtRaq IrsAoKup5DhgsBUaznSzYTl7n2RMpF6o =/Mvv -----END PGP SIGNATURE----- --5kuBRoVe25Cd17OM--