From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by sourceware.org (Postfix) with ESMTP id 72D923857C6C for ; Fri, 16 Oct 2020 21:20:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 72D923857C6C Received: from [192.168.254.38] (unknown [47.187.206.220]) by linux.microsoft.com (Postfix) with ESMTPSA id BA2F720B4905; Fri, 16 Oct 2020 14:20:53 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com BA2F720B4905 Subject: Re: Questions on glibc submission for a new project To: Carlos O'Donell , Ian Bearman , Roman Kiselev , Florian Weimer Cc: libc-help References: <34eb0732-9f09-a862-2c6a-19ac7aa13edc@redhat.com> From: "Madhavan T. Venkataraman" Message-ID: <96820802-f5c5-1e42-e537-a2aca5f47c2b@linux.microsoft.com> Date: Fri, 16 Oct 2020 16:20:52 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <34eb0732-9f09-a862-2c6a-19ac7aa13edc@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-17.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, ENV_AND_HDR_SPF_MATCH, KAM_ASCII_DIVIDERS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2020 21:20:57 -0000 Thanks for the answers. Responses inline... On 10/15/20 3:22 PM, Carlos O'Donell wrote: > On 10/15/20 3:05 PM, Madhavan T. Venkataraman via Libc-help wrote: >> Hi all, >> >> I am planning to submit an RFC for a glibc project. This is my first time. So, I have some >> questions. > > Glad to hear that! > > I look forward to reading and reviewing the RFC. > >> Description of the project >> -------------------------- >> >> I am developing some API functions to create and use trampolines so that applications and >> libraries don't have to each implement them (often using dynamic code). >> >> void *tramp_alloc(int flags); >> void tramp_set_parms(void *tramp, void *code, void *data); >> void *tramp_get_addr(void *tramp); >> void tramp_free(void *tramp); >> int tramp_supported(void); >> >> I will provide a full justification in the RFC. For now, I just have some questions. > > No problem. > >> Copyright assignment >> -------------------- >> >> I am developing these functions under Linux. I see that the files under sysdeps/unix/sysv/linux >> have a "GNU Lesser General Public License". It appears that I should just use that and not need >> to apply for a new FSF Copyright assignment. >> >> Am I correct in my assumption? > > Please have a read through the "Contribution checklist" > https://sourceware.org/glibc/wiki/Contribution%20checklist > OK. Will do. >> If I need to apply for something, could you please advise me on what exactly I need to do? > > I see you are submitting this email via a @linux.microsoft.com account. > > I can't tell if this is a hobby for you or a work project, either way, the rules are the > same and they still apply. > This is part of my work at Microsoft. > I am TO'ing Ian Bearman and Roman Kiselev to see if they can assist you with this internally. > Thanks. > In summary: > - If Microsoft owns the copyright of the code you write then you'll need to go through legal > to get a corporate assignment completed with the Free Software Foundation. This is the same > process that companies like Intel, IBM, Red Hat, Amazon etc. have followed for contribution. > - If Microsoft does not own the copyright of the code you write then you'll need a personal > assignment. > > My suggestion is talk to Ian and Roman and see if there is already a process inside Microsoft > for this. I can tell you that Microsoft has signed an assignment for the GNU Debugger (gdb) > just last year. > OK. > I always suggest getting a future assignment in place which allows us to accept any and all > patches from not into the future: > http://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future > OK. > I also suggest getting GCC GLIBC GDB and BINUTILS assignments all done at the same time. > These 4 core projects constitute the core pieces of the GNU Toolchain and as such it's > sometimes required to synchronize headers across projects. However, to start with you'll > need GLIBC if you plan to contribute to glibc. > OK. >> Placement of the code >> ---------------------- >> >> I have the following files in the project: >> >> - tramp.h (contains the function prototypes of the API functions) >> - tramp.c (contains the common code for creating and managing trampolines) >> - tramp_arch.c (contains architecture-specific C code) >> - tramp_code.S (contains architecture-specific assembly code) > > OK. > >> It looks like I must place the files here: >> >> sysdeps/unix/sysv/linux/tramp.c >> sysdeps/unix/sysv/linux/tramp.h > > > Sure. > >> sysdeps/unix/sysv/linux/x86/tramp_arch.c (etc for each arch) >> sysdeps/unix/sysv/linux/x86/tramp_code.S (etc for each arch) > > > Sure. > >> Did I get that right? > > Yes, that's reasonable. > Thanks. > You'll also need a sysdeps/unis/sysv/linux/tramp_[arch,code].[c,s] > that implements a stub, because I expect you won't add support for all arches > right away? > Yes. I will be addressing X64, i386, ARM64 and ARM to beging with. >> Other OSes >> ---------- >> >> These functions can potentially be implemented for other OSes as well. There are, >> however, some OS-specific details such as mmap() details and traversing the list of >> mapped objects in an address space. >> >> I have two options: >> >> 1. Implement it for Linux. In the future, when it is implemented for another OS, >> deal with the changes required. > > This. > >> 2. Implement it from the beginning as a common feature and provide OS-specific code >> for Linux. > > This is made complicated by the fact that you have to get the design right the first > time for Linux and Hurd. > >> Which one would you recommend? If it is (2), could you point me to an example within >> glibc that I can follow for how to organize the code for a multi-OS feature? > > I recommend (1). > OK. Great! >> Documentation >> ------------- >> >> I do plan to submit a Linux manpage. Do I have to do that after my final patch gets accepted into >> glibc? When exactly do I need to do that? > > Documentation should be added to glibc/manual/*.texi in the appropriate place. > > This includes considerations for threaded safety, signal safety, and cancellation safety. > OK. >> Self-tests >> ---------- >> >> I do plan to submit tests along with the patch. But do I need to submit tests for the RFC? >> Or, is it enough for me to submit tests along with the actual patch later? > > You don't need to submit tests for the RFC. > OK. Thanks. >> mailing list >> ------------- >> >> I will send out my RFC (and an actual patch later) to libc-alpha. Do I need to include >> anyone else in the review? How about folks for each architecture? > > The machine maintainers should be reading the list. > > If there is anyone in particular you want to call out you can do so from the MAINTAINERS list: > https://sourceware.org/glibc/wiki/MAINTAINERS > OK. >> Public header >> ------------- >> >> tramp.h would be a public header file. Is there any specific process I need to follow for >> introducing a public header file? > > No. You just have to convince the maintainers that the API belongs in glibc. > OK. >> Architecture support >> -------------------- >> >> I will be introducing support for X86 and ARM, 32-bit and 64-bit. Is there any special >> process I need to follow if my changes contain architecture-specific changes? > > You will be adding a new symbol to the ABI baseline for all architectures. > > You will need to update all of the symbol baselines with `make update-all-abi` (IIRC). > You will have to explain what other machine maintainers need to do to complete the support. > OK. > Please consider the following: > - Can the functionality be provided by putting the code in another library? Why glibc? > - Is it tightly coupled to PLTs? LD_AUDIT of PLTs? Will LD_AUDIT support the trampolines? > - What do other C library authors think of the interface? You could post to libc-coord. > https://www.openwall.com/lists/libc-coord/2020/01/30/1 > - What are the parallelism and concurrency requirements for the interface? What happens > if multiple threads use the interface and what hardware atomics are required for it? > - How does this trampoline relate to libffi's trampolines? > - Does the trampoline require executable memory? How do you plan to get that under > conditions like SELinux? > Yes. I am thinking about all of these things. > I'm also TO'ing Florian Weimer who has in the past suggested some kind of > trampoline creation interfaces for the dynamic loader. > I had originally sent out an RFC to solve the problem with a kernel API. Florian was one of the reviewers. It was agreed that a user-level solution in a library is preferred. Hence, this project. Again, thanks for the information. I will study this more. Madhavan