From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47327) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WNTOs-0007nl-3k for qemu-devel@nongnu.org; Tue, 11 Mar 2014 16:35:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WNTOm-0008R0-4z for qemu-devel@nongnu.org; Tue, 11 Mar 2014 16:35:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:24589) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WNTOl-0008Ql-KZ for qemu-devel@nongnu.org; Tue, 11 Mar 2014 16:35:40 -0400 Date: Tue, 11 Mar 2014 22:35:34 +0200 From: "Michael S. Tsirkin" Message-ID: <20140311203534.GA11606@redhat.com> References: <20140311161301.GG2450@work-vm> <20140311163657.GH2450@work-vm> <20140311183922.GB10982@redhat.com> <20140311194640.GN2450@work-vm> <20140311200310.GC10982@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH] qemu-thread-posix: Fix build against older glibc version List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Kevin Wolf , Stefan Hajnoczi , Jan Kiszka , "Dr. David Alan Gilbert" , QEMU Developers , Gerd Hoffmann , Anthony Liguori , Laszlo Ersek On Tue, Mar 11, 2014 at 08:27:58PM +0000, Peter Maydell wrote: > On 11 March 2014 20:03, Michael S. Tsirkin wrote: > > Because we don't want people to start relying on thread naming to > > manage the threads outside qemu. > > Then document that it isn't stable; anybody who relies > on it deserves what they get. > If we put a command line > argument on it then people will still be able to incorrectly > rely on thread naming by using the command line option. Where would you document this? The idea was that "debug" in name is a hint. > > There also can be existing tools that would break if > > we changed thread names. > > In this case surely we are already stuck with our current > threading model? I would be anyway happy to say "you > relied on undefined and unstable behaviour so tough"... > > On the other hand, a new command line switch really is > user interface which we have to carry around and support > for ever. > > thanks > -- PMM