From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <> Received: from fx405.security-mail.net (smtpout140.security-mail.net [85.31.212.145]) by sourceware.org (Postfix) with ESMTPS id 935CB386FC0A for ; Wed, 11 Aug 2021 00:54:08 +0000 (GMT) Authentication-Results: sourceware.org; dkim=permerror (bad message/signature format) Received: by fx405.security-mail.net (Postfix) id 85E47323635; Wed, 11 Aug 2021 02:54:06 +0200 (CEST) Date: Wed, 11 Aug 2021 02:54:06 +0200 (CEST) From: MAILER-DAEMON (Mail Delivery System) Subject: Undelivered Mail Returned to Sender To: libc-alpha@sourceware.org Auto-Submitted: auto-replied MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="45590323650.1628643246/fx405.security-mail.net" Content-Transfer-Encoding: 8bit Message-Id: <20210811005406.85E47323635@fx405.security-mail.net> X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, HTML_MESSAGE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2021 00:54:19 -0000 This is a MIME-encapsulated message. --45590323650.1628643246/fx405.security-mail.net Content-Description: Notification Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit This is the mail system at host fx405.security-mail.net. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system : host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1 : Recipient address rejected: User unknown in virtual mailbox table (in reply to RCPT TO command) --45590323650.1628643246/fx405.security-mail.net Content-Description: Delivery report Content-Type: message/delivery-status Reporting-MTA: dns; fx405.security-mail.net X-Postfix-Queue-ID: 45590323650 X-Postfix-Sender: rfc822; libc-alpha@sourceware.org Arrival-Date: Wed, 11 Aug 2021 02:54:06 +0200 (CEST) Final-Recipient: rfc822; mpoulhies@kalray.eu Original-Recipient: rfc822;mpoulhies@kalray.eu Action: failed Status: 5.1.1 Remote-MTA: dns; zimbra2.kalray.eu Diagnostic-Code: smtp; 550 5.1.1 : Recipient address rejected: User unknown in virtual mailbox table --45590323650.1628643246/fx405.security-mail.net Content-Description: Undelivered Message Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) by fx405.security-mail.net (Postfix) with ESMTPS id B2F59323635 for ; Wed, 11 Aug 2021 02:54:04 +0200 (CEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6BA273861C5A for ; Wed, 11 Aug 2021 00:54:01 +0000 (GMT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 2219C385BF93 for ; Wed, 11 Aug 2021 00:53:45 +0000 (GMT) Received: from mail-pl1-f198.google.com (mail-pl1-f198.google.com [209.85.214.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-284-hOqQ9hJhOt-t3jWX2sYzxg-1; Tue, 10 Aug 2021 20:53:43 -0400 Received: by mail-pl1-f198.google.com with SMTP id f4-20020a170902ce84b029012ccdab6e58so258098plg.0 for ; Tue, 10 Aug 2021 17:53:42 -0700 (PDT) Received: from mickey.themaw.net ([180.150.83.225]) by smtp.gmail.com with ESMTPSA id n32sm3543071pgl.69.2021.08.10.17.53.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Aug 2021 17:53:41 -0700 (PDT) X-Quarantine-ID: <0BztHh_RYqnB> X-Virus-Scanned: E-securemail, by Secumail X-Spam-Status: No, score=-3.149 tagged_above=-1000 required=7.5 tests=[AB_ENVFROM_LONG_40=0.5, AB_IN_REPLY_TO_EXISTS=-1, AB_LONG_SUBJ_30=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-1, DKIM_VALID_AU=-0.1, FSL_RCVD_EX_5=0.01, FSL_RCVD_UT_5=0.01, HEAD_NEWS=-0.5, MISSING_MID=0.14, MM_ENVFROM_BOUNCE=1, NICE_REPLY_A=1, RCVD_IN_DNSWL_MED=-1.3, S_FROM_GREY_MINUS_2=-2, T_RP_MATCHES_RCVD=-0.01] autolearn=disabled Authentication-Results: fx405.security-mail.net (amavisd-new); dkim=pass (1024-bit key) header.d=sourceware.org Secumail-id: <159c2.61131fac.6ff3b.0> DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6BA273861C5A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1628643241; bh=QYOZrnDK2SSm82543AqwEYtGU2sgIwBt8kN8wjvdfX8=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=lwypgScZ68xX7k2AOIVVL0mVeuu7UVy3J+IBjG2Ph6ByJcrZNih+hOUxy9Eypyi8H hW4Y5M0KSj3d3kzqbeIkOCASKFFwwND6d0POwQsS6ggA2Y1tMixtjoz0NbxF2zX+uB TG/8O9SkPGnhU8hS1iavlef1JBZChGQjx/tXcxyk= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2219C385BF93 X-MC-Unique: hOqQ9hJhOt-t3jWX2sYzxg-1 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=izmkBnmfpVrTPNCVVzVIRSXdiCeOFUjzdqSqt52a4z4=; b=qG0iLG9SC6tieJ+SWdArkkQn198oOcKakklJm6VjVyF0qfddqjC71yKPw6Yi2QEZOE IJj18z9WWLw0lZqHYvzqAcUofpBBuSNDe8pJWEGfcc7U9XBmOV7FOorbMrxumGEaqeoy iov54EmbVPvqDUeIrmpislJGROe4djSSodoPg0CCBJeRrkkhYbVasLf3Eq2rR2p8jtdp EN5m+bIxOo/vZ7zW9HOv8ceJJzKp93XCqm27w2EUygsNtJH0S0SIuEq1TKNx/gfGjPK7 IPGOwKmIsvqHvGMc8fcXTp0ojt+BG8Z60DSgVStGzNu8IOYTWNVcFJRqTlOwhL6Ltefv v1iQ== X-Gm-Message-State: AOAM531Et/xM5iPepJwuDO+J8SaLqCOSlwHoCH150eAJIvAK4DFmDU1b hScFhJVa0dfHC4F3ZML6c3Wkbjgt0BkEi4oET8PkdhZMJz5rmAL9q3Z8l+N052SGbPhf5QK9RSf NB2J8wZDojgJ6JlT4kEZH X-Received: by 2002:a63:3c7:: with SMTP id 190mr34825pgd.240.1628643222089; Tue, 10 Aug 2021 17:53:42 -0700 (PDT), by 2002:a63:3c7:: with SMTP id 190mr34806pgd.240.1628643221841; Tue, 10 Aug 2021 17:53:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzknE6qofA9pXP1pmSliZQN5qqUDkuT33tHi/5WKXvHkuVGcqAUfYy3ZIuCcovpc8DZN+98Ug== Subject: Re: Building sunrpc from glibc source To: "Binello, Severino" , libc-alpha@sourceware.org, fweimer@redhat.com, "Marusic, Aljosa" References: <88153f7a-5c2b-779d-16b5-6fcd00abcd07@redhat.com> Message-ID: <8e080640-21f1-5da3-3617-2a137faf54cb@redhat.com> Date: Wed, 11 Aug 2021 08:53:36 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-us X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Ian Kent via Libc-alpha Reply-To: Ian Kent Errors-To: libc-alpha-bounces+mpoulhies=kalray.eu@sourceware.org Sender: Libc-alpha X-ALTERMIMEV2_in: done Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 11/8/21 1:47 am, Binello, Severino wrote: > Hello Ian and Florian > > Thanks for the feedback, its much appreciated > Unfortunately Im not the best person to be asking the questions or > providing the info > My role with our communication code right now is to get it to build > > I am reaching out to the developer of our rpc based code to see if he > can provide > a better picture and provide  further information. > So I am including Al Marusic in this email thread. Ok. Don't get me wrong, I do understand the potential difficulty changing to libtirpc. But glibc rpc has been on the chopping block for years so there's been plenty of time to investigate and change. At the very least some analysis needs to be done about the application rpc usage to understand where the difficulties are. Certainly, if you use low level rpc calls (in order to take control of timeouts and such) the work would be substantial but if your using higher level rpc calls it might not be so bad. TBH the application I maintain does need to use lower level rpc calls so using libtirpc was a significant change for me, but that was a long time ago now. Bottom line is that libtirpc is thread safe but it depends on the rpc calls that are used. Ian > > Thanks again! > -Sev > > ------------------------------------------------------------------------ > *From:* Ian Kent > *Sent:* Friday, August 6, 2021 8:27 PM > *To:* Binello, Severino ; libc-alpha@sourceware.org > > *Subject:* Re: Building sunrpc from glibc source > > On 6/8/21 8:07 pm, Ian Kent wrote: > > On 6/8/21 7:12 am, Binello, Severino via Libc-alpha wrote: > >> Hello > >> > >>    As of RedHat 8, the sunrpc is no longer included with glibc shared > >> object library. > >> Unfortunately, our communications software would require extensive > >> redesign in order to use tirpc. > > > > For example? > > > > Can you describe the sort of challenges you have doing this please. > > > > > >> As such, we are looking into an alternative approach where we just > >> build the sunrpc portion from the glibc source tar file. > >> However, running into difficulties separating it out. > >> Can you recommend a method for just building the sunrpc code ? > > > > It's worth understanding what might be needed in order to use libtirpc > > > > first. > > > > > >> > >> Thanks Much > >> -Sev > >> > >> ps: Below is the reason why our code is incompatible with the tirpc > >> design > >> with old glibc every RPC server runs in its own thread, > >> with tirpc library there can be only one RPC server per program. > >> See: > >> from svc.c of tirpc library: > >> > >> static struct svc_callout /* removed declaration */ *svc_head; > >> > >> from svc.c of glibc-2.25: > >> > >> #ifdef _RPC_THREAD_SAFE_ > >> #define svc_head RPC_THREAD_VARIABLE(svc_head_s) > >> #else > >> static struct svc_callout *svc_head; > >> #endif > >> > >> As you can see, if RPC_THREAD_SAFE_ is defined, > >> svc_head is per thread variable. > > > > I think I have some quick and nasty multi-thread libtirpc svc code > > > > kicking around somewhere (if I can find it now). It might be worth > > > > cleaning that up and maybe enhancing it a little, or maybe it's broken > > > > I don't know, but I'd recommend looking at that first, if there's not > > > > to many other problems to deal with. > > Actually it looks like this was multi-threaded io not multi-threaded > servers. > > > But I'm not sure that you can't register multiple services in both glibc > > and libtirpc, it's just that it's not thread safe to do so in glibc. > > > Maybe I don't understand what your doing, explain it please. > > > Why do you need a separate services list for each thread rather than a > > library global lock protected services list as in libtirpc? > > > Ian > To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=159c2.61131fac.6ff3b.0&r=mpoulhies%40kalray.eu&s=libc-alpha-bounces%2Bmpoulhies%3Dkalray.eu%40sourceware.org&o=Re%3A+Building+sunrpc+from+glibc+source&verdict=C&c=0198a7272b86f871dfb7eb689d2f929c9aeddf13 --45590323650.1628643246/fx405.security-mail.net--