The reentrancy structure?

[H. Peter Anvin]

J. Johnston wrote:
> 
> The reentrancy structure is tightly integrated into newlib.  Can you explain
> in greater detail what you want to do?  For example, what do you do
> differently if you find out stdin is linked in vs if it isn't?  
> 

Absolutely.

My platform doesn't have shared libraries, nor does it have device 
drivers for anything but bulk storage.  Therefore, device drivers have 
to exist in user space.  stdin et al therefore require the presence of 
the console device driver.  For open() I'm relying on magic strings, 
like the following [simplified]:

extern const struct __device_driver __dev_console;
#define DEV_CONSOLE ((const char *)__dev_console)

	fd = open(DEV_CONSOLE, ...);

... which means that the reference to __dev_console would pull the 
console device driver into the program.

However, stdin/stdout/stderr are presumed to be already open, which 
means the device driver for the console.  Since not all programs are 
likely to actually use this functionality, it's a real waste to link 
this code into all programs.  What I was hoping to do was to write a 
module like this:

FILE *stdin, FILE *stdout, FILE *stderr;

int __init_stdio(void)
{
	stdin = fopen(DEV_CONSOLE, "r");
	stdout = stderr = fopen(DEV_CONSOLE, "w");
	return !(stdin && stdout);
}

/* Through linker magic, iff this module is linked in, add
    __init_stdio to the list of functions to be invoked
    before main() */
INIT_FUNC(__init_stdio);

[The linker magic is simply a separate section containing a list of 
pointers to functions to be invoked by crt0.S.]

	-hpa