From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19313 invoked by alias); 3 Mar 2017 12:28:35 -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 19294 invoked by uid 89); 3 Mar 2017 12:28:35 -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=guideline, flexibility, 02-Mar-2017, 02-mar-2017 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-pf0-f193.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=8PptEDOOgww+dA+771KRGT+bifRelQg9YoO7zvpQXW0=; b=cLRx6YkpbFHanSNDcOjtrC+gtRcl5Hp6VZZHr2+gR+oDsa+dDR0a+UwSr8o3+Z0Tck ti+OBB5bkl6bF628t/IiHGIUY3d12ROpIzWcgUVdTBhrDOSgO0vIi0r/bbzheWa9QEZ6 IqyGYBjIjIKLo0pVhT8I7CcUuZKShw9bKWTaysaeYPTzU7froUhcWt1kn5y2G79ryn2i Dh80ebzd7VKsxYqQiexORjVgGFCL88trboQVV7ukTfCzCIrOc33RRkgR6vhStwR3S5G1 BUOaKypwpfvdFOMdQyK9QXWPTSUUkixTDjLp4awbnVtKk9be3+21MeyrrK83UUF1tYZw tHIA== 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=8PptEDOOgww+dA+771KRGT+bifRelQg9YoO7zvpQXW0=; b=B2AKDeCyftNAT1XYy3JMKAWLByl5ot2zfOPcv0/vJ58ySZw6xOllMsY/yniTUFrQY2 WrDcCb5NKrhLTb7UWqVKgBk4knNO6A5L3mmZ3lQhmMqNnQozR2tJHkhsWGhRJuT1GCWK akAlweuVpg7okX8tpv+5tIlx7eGUa1DE5tMbiQNMqQANM6Hm6k03G3L2/9+5QFKIzHOH h8XIEZ1+BH5FNMbRMIX2DSuKTZlWYqdXgPqYdlJ227UXScxH6RIZ4Mw6kZL/To8NZ90D heB8URf8QVeODBU3cBSuhuecegcQZH2iXgex+6QKEwBPIFbm1AKiFoIOGGCeFmcQlDcE z9Vw== X-Gm-Message-State: AMke39nOXQMhAuBJbufDybVM6jQbE6kwzs98fVEImmtm+CKI1nxxOw5kxWIoFEAjCcbeNA== X-Received: by 10.98.93.150 with SMTP id n22mr3215001pfj.103.1488544112840; Fri, 03 Mar 2017 04:28:32 -0800 (PST) From: Suprateeka R Hegde Subject: Re: RFC: ABI support for special memory area Reply-To: hegdesmailbox@gmail.com References: To: "H.J. Lu" Cc: gnu-gabi@sourceware.org Organization: HEGDESASPECT Message-ID: <88608944-14c9-9d28-80d1-32283521683b@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.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 170303-0, 03-03-2017), Outbound message X-Antivirus-Status: Clean X-SW-Source: 2017-q1/txt/msg00009.txt.bz2 On 02-Mar-2017 09:34 PM, H.J. Lu wrote: > On Thu, Mar 2, 2017 at 7:16 AM, Suprateeka R Hegde > wrote: >> On 23-Feb-2017 09:49 PM, H.J. Lu wrote: >>> >>> The default implementation of __gnu_mbind_setup is >>> >>> int >>> __gnu_mbind_setup (unsigned int type, void *addr, size_t length) >>> { >>> return 0; >>> } >>> >>> which can be overridden by a different implementation at link-time. >>> >> >> Since this is a design that allows vendor specific extension and >> implementation, would it OK if we make it more generic? > > Yes. > >> Instead of a fixed 3 arguments (type, addr, len), how about something like a >> pointer to a generic MBIND_CONTEXT struct (say of type __gnu_mbind_context >> defined)? And let the implementation define the actual struct. > > We can add more arguments. But they must be predefined since > __gnu_mbind_setup is called from ld.so which must know what to > pass to __gnu_mbind_setup. > __gnu_mbind_setup is platform specific. We can pass as > much as we need to __gnu_mbind_setup. But they have to be fixed. I didnt understand this. Predefined/fixed where and how? As part of the ABI support? Or part of the implementation? If it is going to part of ABI, then we need to finalize and define it now. If it is part of the implementation, then __gnu_mbind_setup must be documented in the ABI as just a guideline to the implementer. What I meant by being generic is to have flexibility in number of arguments. Here is an incomplete/pseudo code of what I am trying to tell: enum __gnu_mbind_instance { GNU_MBIND_DEFAULT, GNU_MBIND_OVERRIDDEN }; typedef struct { __gnu_mbind_instance mb_inst; // mandatory. ABI specified #ifdef VENDOR_1 type1 identifier1; // optional implementation defined type2 identifier2; // optional implementation defined ... typeN identifierN; // optional implementation defined #endif // Add vendor/implementation as necessary } __gnu_mbind_context; int __gnu_mbind_setup(__gnu_mbind_context*); Now, for MCDRAM instance, from my understanding: typedef struct { __gnu_mbind_instance mb_inst; #ifdef VENDOR_MCDARM unsigned int type; void *addr; size_t length; #endif } __gnu_mbind_context; int __gnu_mbind_setup (__gnu_mbind_context* mbind_context) { /* Even if real implementation exist, check and allow disabling special memory bindings */ if (mbind_context->mb_inst == GNU_MBIND_DEFAULT) { return 0; } else { // return real_implementation_result; } } If that is not what you are telling, I want to understand how to use it vendor specific way. >> I would like to handle NVM/NVMe (long back I had mentioned about >> PT_PERSISTENT) through this MBIND and my implementation of handling NVM/NVMe >> needs more data to be passed to such "setup" functions. > > I call it MBIND since a MBIND segment is inside a LOAD segment and > my real __gnu_mbind_setup will call mbind to move a MBIND region to > a NUMA node after it has been loaded and relocated. We can give it > a different name if you have a better one. I dont have any comment on this MBIND naming. It sounds good. -- Supra