From owner-freebsd-arch@freebsd.org Sat Oct 1 20:17:08 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 59E8BA94D1D for ; Sat, 1 Oct 2016 20:17:08 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mailout.stack.nl (mailout05.stack.nl [IPv6:2001:610:1108:5010::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 26F01131; Sat, 1 Oct 2016 20:17:07 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mailout.stack.nl (Postfix) with ESMTP id F16796B66; Sat, 1 Oct 2016 22:16:55 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id E2C7728494; Sat, 1 Oct 2016 22:16:55 +0200 (CEST) Date: Sat, 1 Oct 2016 22:16:55 +0200 From: Jilles Tjoelker To: Konstantin Belousov Cc: Alexander Kabaev , Lewis Donzis , deischen@freebsd.org, freebsd-arch@freebsd.org Subject: Re: mq on kqueue broken after upgrade to FreeBSD 11 Message-ID: <20161001201655.GA91457@stack.nl> References: <8A6CD0D3-C4D5-40DF-B2AD-4C454CC88AD1@perftech.com> <20160930094544.GP38409@kib.kiev.ua> <19A6EEAA-C68E-4DAD-B98F-4D904734BD8B@perftech.com> <20160930152006.GS38409@kib.kiev.ua> <20160930184418.1047afc2@kan> <20161001092515.GW38409@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161001092515.GW38409@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2016 20:17:08 -0000 On Sat, Oct 01, 2016 at 12:25:15PM +0300, Konstantin Belousov wrote: > On Fri, Sep 30, 2016 at 06:44:18PM -0400, Alexander Kabaev wrote: > > No objection, but possible suggestion: if the primary use of this > > symbol is for tests and nothing else, maybe it does belong in > > FBSDprivate_1.0 FBSDprivate_1.0 section instead? > Good question. The symbols are useful for real-world code, not only for > the tests. But I think that we should mark symbol as non-portable. Usual > approach of adding _np suffix seems to be the right thing to do there. > What about the following ? The idea is good, but perhaps call the function mq_getfd_np() to clarify it returns a file descriptor. Also, the __ versions should not be exported since they are not used outside the library (they can be exported if and when needed). -- Jilles Tjoelker