From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84185 invoked by alias); 10 Jun 2016 18:01:30 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 84172 invoked by uid 89); 10 Jun 2016 18:01:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=faithfully, skilled, quality, stand X-HELO: mail-qg0-f42.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=XvuPRsNJl3f1/XFT63ksURb6guYPDDC04Z2T2X0E8+k=; b=iJ5Huj73wGQqix9KHidAOWQa8h15+2JQMWfYUJpL5u5EG0ijrMoB6y3x/iAgLn2a8l MG2LaHOCEdbqBm3CUTJIfRihBmM4Mnauk9IpMMZSSHlbJWvrRsghF+MGE399rbgwj7cW m/VWuJP5YxbmAoDa9Ybysw3tcIPZAabBnmmnSrjfgq9+pmXFny4HOzMSTf5yaBfYYzEi od3wBcJ1trYo3eYTqBfiWGkvkPXzw8xEr7MzSqAh47neEi700pn0wvJMFN1pOgvxIbr/ AwJXCBzULF1sBWyeuaFS6Fj8hiOb3ya5EThKTXvbOBm8fERv/A7LjvY3t5HUmbkKuIsQ HxsQ== X-Gm-Message-State: ALyK8tJLIW1+Wj2S5I2MCkpswud5xUA65xZSk4uA9Zt+2nZu7paKMcyX5TM5iUD2+Wa0LIzJ X-Received: by 10.140.18.244 with SMTP id 107mr3014821qgf.95.1465581686480; Fri, 10 Jun 2016 11:01:26 -0700 (PDT) Subject: Re: [PATCH 2/3] network: recvmsg and sendmsg standard compliance (BZ#16919) To: Zack Weinberg References: <1459175641-12520-1-git-send-email-adhemerval.zanella@linaro.org> <1459175641-12520-3-git-send-email-adhemerval.zanella@linaro.org> <5756D873.1000701@linaro.org> <575886C8.8000401@linaro.org> <5758DFF7.5020800@redhat.com> Cc: Adhemerval Zanella , GNU C Library , Florian Weimer , Joseph Myers From: Carlos O'Donell Message-ID: <4ce169ed-9dc2-9bcd-e66d-7443b371befa@redhat.com> Date: Fri, 10 Jun 2016 18:01:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-06/txt/msg00381.txt.bz2 On 06/09/2016 09:35 AM, Zack Weinberg wrote: > On Wed, Jun 8, 2016 at 11:18 PM, Carlos O'Donell wrote: >> On 06/08/2016 04:57 PM, Adhemerval Zanella wrote: >>> On 08/06/2016 17:15, Zack Weinberg wrote: >>>> What would persuade you to accept *my* position on this issue? >>> >>> I am stating we follow POSIX to very reason we follow other technical >>> standard: to provide libc compatibility. >> >> There are some places where POSIX and Linux disagree. >> In as much as we possibly can we should try to standardize on POSIX. > > Right, so as I have been saying all along, I don't agree with this; I > think it is *more important* to faithfully reflect the semantics of > each supported kernel. If that means that glibc-on-Linux has > different semantics than glibc-on-FreeBSD (for instance), well, that > was probably unavoidable anyway. That's fine so long as you don't pretend to be POSIX-compatible. > The reason for this is that POSIX is very slow, and the C library > should not stand in the way of *improvements* to the kernel interface. It doesn't stand in the way. We have lots of interfaces that are non-POSIX and we aren't touching them. > The case we're arguing about is relatively minor, but maybe someone > has an actual need for size_t-sized ancillary data buffers - I don't > think we should be judging whether that is a valid use case. The problem I have with this line of argument is that a standards-conforming interface name was taken and changed. If you really wanted size_t sized ancillary data buffers we should have just declared a different type and new functions to handle that. It's that easy. > (A much more significant issue here is the ridiculous delays in adding > things like gettid() and getrandom().) There are no delays in adding gettid or getrandom, there are only the lack of skilled people willing to do the work at level of quality required of a core library implementation. >> Each decision should be done on a case-by-base basis, and I think in >> this case of recvmsg/sendmsg it is possible to comply with POSIX without >> serious problems. I've only seen rare examples of theoretical breakage, >> and the reported dlsym issue simply needs fixing in the dynamic loader. > > I do not think the reported dlsym issue is a simple matter to fix. I > haven't sat down and worked it out, but I am fairly sure it is > possible, for most symbols that glibc exposes multiple versions of, to > construct a pair of interposition modules which are black-box > indistinguishable except that one of them needs version A and the > other needs version B -- which is to say, whatever dlsym("name", > RTLD_NEXT) does, it's going to be wrong for one of them. Which is why > there is dlvsym()... but changing the semantics of dlsym() strikes me > as asking for much greater breakage. The entire dlsym/dlvsym discussion is a red-herring. At some point you'll need to interpose yourself in front of a versioned interface and you'll need two things to do it properly: * A versioned symbol of your own. * Use of dlvsym(). Anything that doesn't work with this setup is a bug we need to fix. Fixing dlsym() is a required fix because the semantics are just plain wrong, and it happened to fix the present use case, but eventually it doesn't work. -- Cheers, Carlos.