From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48395 invoked by alias); 2 Mar 2017 16:04:58 -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 48363 invoked by uid 89); 2 Mar 2017 16:04:56 -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=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=numa, NUMA X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mail-qk0-f179.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Yt5RYxKxIIe/LQt7BPz8YGXvm4rJTgTFnZKaEelp20M=; b=DD9JUOnYPRGQt2p3BzTdP41C3wRl09EepzpP/3ex4x78b2QwxgHKLRiItQFRnucP5n cDExQ6QGuDPFhxgSn3EBfwipanTzbQDMFP7xi8xF08YQcvnvELSVph9+3tCvyOO86zCY 3nJ4Eyfk+fRvlIG4sEs2MCqb4l0Og02bKULjqyM3MkcCuH/dU6RJUOmG4QxSPDO8Ax0H o2sXWDWrCGbG1CNOZEtfHg+DJCG2RRrGohgztNeoNm7T/gwYJis5bPpny5BZEA2jUCm8 yzTz7mNp29kVcmv9gUWkpfR5KBW5ht0To0TSQUxy+RyDpfaHmwWY17JuWle82abv7qZp RGSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Yt5RYxKxIIe/LQt7BPz8YGXvm4rJTgTFnZKaEelp20M=; b=aV/iTY6lqRJr7z10rI0wpjYvfBaT0yp8oSVKlxr/LBG4pNxw8x+2pN7sOjsbZwbKPr pOg9WXG3q6oDol4L4M8s/pn+0Aiqd1K92cgdniDCCUtB57qBjif0Pi+35E72yJDvc1wk 3y7jBpskbAgzGy7pTZny+BClnjp1ZYV9Bigk8sprINz/7VAfS1xkFj1QWnps+6GpU55D BGrRvFGsiQIDoAbJiYmLS1hpi7ZvW4YtLK/fkdvxJsKldKDlBhGNr+jQjDdw5gi9uevw g+z83DsxWT/xlmgSQAKAv6iab599DLs6VONFH4yyTQ/DjS+KX0l6ZUHdy9RCPHi2enPW VWRw== X-Gm-Message-State: AMke39nNtDk9HS2/MbJE28+3jk0elE42r/+DCU4GvTOeapdGQlTPpndn/Sy+jcdIvFJ5XH8JQhfzSmHDnMA+Nw== X-Received: by 10.55.11.10 with SMTP id 10mr17605265qkl.100.1488470693226; Thu, 02 Mar 2017 08:04:53 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: From: "H.J. Lu" Date: Sun, 01 Jan 2017 00:00:00 -0000 Message-ID: Subject: Re: RFC: ABI support for special memory area To: Suprateeka R Hegde Cc: gnu-gabi@sourceware.org Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2017-q1/txt/msg00008.txt.bz2 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. > 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. > Or is this __gnu_mbind_setup should be considered as a very basic / > fundamental function (used just to setup the "memory area") and > implementations/vendors are expected to write wrapper/handler functions to > handle other aspects of the special memory? In that case the fixed set of > basic args looks OK. That is correct. __gnu_mbind_setup is platform specific. We can pass as much as we need to __gnu_mbind_setup. But they have to be fixed. > IMHO this __gnu_mbind_setup is a very good design to be generic enough and > not be very specific/basic/fundamental runtime support. > Thanks. -- H.J.