Questions on glibc submission for a new project

["Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>]

Hi all,

I am planning to submit an RFC for a glibc project. This is my first time. So, I have some
questions.

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.

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?

If I need to apply for something, could you please advise me on what exactly I need to do?

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)

It looks like I must place the files here:

	sysdeps/unix/sysv/linux/tramp.c
	sysdeps/unix/sysv/linux/tramp.h
	sysdeps/unix/sysv/linux/x86/tramp_arch.c (etc for each arch)
	sysdeps/unix/sysv/linux/x86/tramp_code.S (etc for each arch)

Did I get that right?

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.

2. Implement it from the beginning as a common feature and provide OS-specific code
   for Linux.

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?

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?

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?

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?

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?

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?

Thank you all in advance for your guidance. Much appreciated.

Madhavan