This is the mail archive of the
newlib@sources.redhat.com
mailing list for the newlib project.
Re: The reentrancy structure?
- From: "H. Peter Anvin" <hpa at zytor dot com>
- To: "J. Johnston" <jjohnstn at redhat dot com>
- Cc: newlib <newlib at sources dot redhat dot com>
- Date: Mon, 08 Jul 2002 11:37:37 -0700
- Subject: Re: The reentrancy structure?
- References: <3D263590.3030703@zytor.com> <3D29D9DB.949EAAD0@redhat.com>
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