From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97237 invoked by alias); 16 Mar 2017 17:18:19 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 97217 invoked by uid 89); 16 Mar 2017 17:18:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=HX-HELO:sk:mail-it, H*RU:209.85.214.66, Hx-spam-relays-external:209.85.214.66 X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mail-it0-f66.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:reply-to:references:to:cc:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=WNLaFnT5JzD0vEvk34zQGOFG+R2qLB3y82K0/y8VeDs=; b=ImIWbqB0kyvQnR82BqWp4+pkacM6uT+iEbFbPKlMiFsg2F4YkQccaUgb1mbmowYhAE 1n5p+VKVyeflPJBmrhzFwZQzkqbgDl4TNxaQvuwU+cMsV38X3/Lq/wAnaMUUK1nIUiRR U3hIuq/ATU/px/PR9HQhYdE7tUarmqWYvItUoqi9dZBrMXyYLLbSlokFGo0Z6KbnpzvG hlNq24HD4yzTA9biD7pXU2lvz77IxXwHbfXhOxFiIjYWPCPJC2UyIqvBvVhDOYBHdr1q 72s2fQ2oK6bu5qMkmL+OPzAujo30G/YtxKlZ2iOAJEZ6b3ajybszU1XK2seCB/GUNQN+ TQWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:reply-to:references:to:cc :organization:message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=WNLaFnT5JzD0vEvk34zQGOFG+R2qLB3y82K0/y8VeDs=; b=h46X/QPQcfn5IQbweknSUvfgmFM0HMC4GF1xz/vLTY6T8hCe6KZTfGLhmrvWEKEbWi Er+kICwzMZXQRUSUJT9b5QLDcMUq5UMjkk3DWn8noFOXaln74jwD/6PvWh/3FBi4qnDL Dv8NhPUEUN1MdtguUASLf+oDW5pttb/5rSmwSXOoQOM7gCfHI8Ey+YurOYX8CiOBrXeb gOJ1yjijd4LJBZU5quBkBBliMAfcUgSDVyKHtrkyUVng57UfOZMm6NwUsW5Y6zh6e/Lj CiSQglVQzeMrzdAugIQtSDvuZbexJmKJV936jUh+pafsOCq2PjCH1psRRFFnj02rnhc0 F1Mg== X-Gm-Message-State: AFeK/H1rH5v/WLmZqYYZzjcevxsZP+qGRdGFo5nZonkv9QTxRAeB4FuCLySfBHDykcuSpA== X-Received: by 10.107.25.73 with SMTP id 70mr10506123ioz.231.1489684691357; Thu, 16 Mar 2017 10:18:11 -0700 (PDT) From: Suprateeka R Hegde Subject: Re: RFC: ABI support for special memory area Reply-To: hegdesmailbox@gmail.com References: <88608944-14c9-9d28-80d1-32283521683b@gmail.com> To: "H.J. Lu" Cc: Carlos O'Donell , gnu-gabi@sourceware.org Organization: HEGDESASPECT Message-ID: <1d183289-5789-8443-7db8-59816bfdd44c@gmail.com> Date: Sun, 01 Jan 2017 00:00:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 170316-1, 16-03-2017), Outbound message X-Antivirus-Status: Clean X-SW-Source: 2017-q1/txt/msg00018.txt.bz2 On 16-Mar-2017 03:33 AM, H.J. Lu wrote: > Run-time support > > int __gnu_mbind_setup (unsigned int type, void *addr, size_t length); I still think the above interface is specific to MCDRAM proposal and is not generic enough for other special memory types. I would prefer it more in the form of something I showed. Or something even better than what I showed for the ABI support documentation and hence glibc implementation. > > It sets up special memory area of 'type' and 'length' at 'addr' where > 'addr' is a multiple of page size. It returns zero for success, positive > value of ERRNO for non-fatal error and negative value of ERRNO for fatal > error. Let me rephrase what I want to know or what I am telling. Assume my interface of __gnu_mbind_setup is as follows: int __gnu_mbind_setup (unsigned int type, __nvm_kmem_t *nvm_kmem_obj, size_t length); Then, What is the expected way to add the default implementation for this vendor specific interface in glibc? Because this differs from the interface seen in glibc (from your patch). Are you saying we should use #ifdef for default implementation of every vendor? And hence a vendor specific ld.so? I dont think this is what you meant as this has lot of obvious problems. Or are you saying that we do not add vendor specific default implementations at all in glibc and just keep one interface and one default implementation that you have mentioned? And then the real implementation (with a different interface) would override glibc one (with the interface you have defined)? If that is what you are designing, it looks like the overriding is purely based on the symbol name and not the the full interface of the function. Personally I feel this is a overriding hack based on linker/loader symbol resolution magic. Since ld.so is not meant only for programs with C style linkage, what if the real implementation library is written in C++ and wants to export only mangled names (interfaces) without any "extern C" kludge? Or is this considered to be a standard C library call just like mmap etc.? And you may also want to define the flow for fully archive bound static binaries. Assuming I am not missing anything above, if you still want to keep the interface as defined by you currently, I am OK with that. But we should at least add a couple of lines in addition, something like: "...which can be overridden by a different implementation at link-time. Such an implementation is required to provide a C style (unmangled) __gnu_mbind_setup function. However, the arguments and return type of the function need not match the one defined here" BTW, what if the real implementation library also includes stddef.h? Wont there be prototype difference if the vendor implementation/interface is different? -- Supra