This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Confirming porting strategy


I want to outline our current porting strategy. I suspect it is generic,
but perhaps we have missed something that someone will be able to point
out and save us a bunch of time.

For our "round 0" port, we are attempting to get a version of glibc in
which:

  1. All system call stubs return ENOSYS. This is turning out to be
     pretty easy, since it is what the generic/ tree does.

  2. Multithreading is not supported

  3. There is no explicit support for thread-local storage. However,
     it is not a problem to arrange a linker script so that data items
     in the thread-local region are (as a temporary porting expedient)
     simply included in the .data region.

Once we get this much running, I'll tackle TLS support and start
figuring out what to do about system calls (Coyotos isn't a POSIX
system).

We are already committed to the ELF object file format, and we are
mostly targeting existing hardware platforms.

Is there some obvious consideration that we are missing?

shap


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]