h1. Porting glibc to FMI/OS

The porting of the GNU glibc to the FMI/OS platform serves two purposes.

  1. To bring a modern posix complicant libc to the environment
  2. Outline short issues with the FMI/OS design in order to improve various interfaces.

At current the glibc is a work-in-progress and as such it is incomplete. We are taking our time doing the port as this is a prime opertunity to rethink various interfaces and clean up areas that are prone to problems. This page tries to outline what has been done, and what still needs to be done.

h1. glibc FMI/OS add-on

The FMI/OS port itself currently exists as a glibc add-on package. This means that the port needs to modify very little of the glibc source. The current patch to glibc only makes the i*86-fmios build target valid. The rest of the FMI/OS specific code is maintained in the add-on tree.

h2. Getting the source

While at this time it is not possible to fully build glibc targeted to FMI/OS, it is possible to help debug issues and submit patches to get the source fixed up. To do that one must first retrieve the [ftp://ftp.gnu.org/gnu/glibc/glibc-2.3.6.tar.gz glibc-2.3.6 source code] and extract it.

After the glibc source has been extracted, cd into the glibc-2.3.6 directory and retrieve the fmios add-on with the bzr command:

bzr get http://fmios.ocgnet.org/archives/source-pqm/system-libs/glibc fmios

Contained within the fmios/ directory is the patch to glibc needed to get it to recognize the i386-fmios build target.

patch -p1 < fmios/glibc-2.3.6.patch

h2. Building the source

One should avoid building glibc from the top-level glibc source directory. This can cause a lot of annoyances when attempting to make changes to the source. The prefered method for performing a build is from a build directory. Assuming your current working directory is inside of glibc-2.3.6/

mkdir build
cd build

Assuming all the above steps worked correctly, it should be possible to configure and build the source.

../configure --host=i386-fmios --with-elf --without-tls --without-+thread --disable-shared  --disable-profile --disable-sanity-checks --enable-hacker-mode --without-gd --enable-add-ons=fmios

Explaining the options: ** --host=i386-fmios - sets the environment we are targeting glibc to operate in as an fmios system running on an i386 compatible processor. ** --with-elf - enable elf support ** --without-tls @--without-+thread@ - turn off Thread Local Storage ** --disable-shared - do not compile for a shared library environment ** --disable-profile - turn off profiling support ** --disable-sanity-checks - this is pretty much needed until the port is complete ** --enable-hacker-mode - like the sanity-checks above, this is needed until the port is complete. ** --without-gd - for whatever reason, glibc tries to compile a memory usage tool that uses libgd, even if cross compiling the library. ** --enable-add-ons=fmios - Enable compiling the fmi/os add-on as our target

At this point it should be possible to type make and compile the source. Please do not expect it to succeed, as mentioned before, the port is incomplete.

h1. Approach to porting

The approach being taken at current with this port is to try to do as little as reasonably possible in the port. Much of glibc itself is very portable and quite a few portable components already exist in the glibc source that can be used by FMI/OS. One of the most interesting aspects here is that some components are just slightly different then what glibc (and other libc's) expect. While it would be possible to supply low level routines for doing everything that glibc requires, it is not entirely productive to improving the FMI/OS platform and long-term maintainability of the port. In that regard, some parts of FMI/OS are being reworked to better intigrate with glibc. As some of these changes are already intrusive to the FMI/OS usermode and kernel environments, this is a good opportunity to clean up other aspects of the system that are found to be lacking.

In an effort to increase portability, glibc performs some include path trickery, this sort of work allows for a port to inherit functionality from other parts of the system. One of the annoying drawbacks to this sort of behavior is that inheriting functionality is not very selectable, one tends to inherit large chunks of another system which may include dependancies on writing even more handlers. Quite a bit of effort being done at this point is attempting to inherit various pieces of functionality from other areas where possible and keep the list of things we have to maintain in our port reduced. Thus the work progresses fairly slowly.

h2. Completed == glibc add-on === Enabling the FMI/OS port as a glibc add-on port. Pretty much copied the core idea from the glibc-ports package.

h3. _exit()

glibc was understandably unhappy about this not being defined

h3. syscall()

Implemented syscall() in glibc that follows a proposed syscall interface that should allow reworking a few other syscall's for better performance. i.e. the msg_* subsystem. The basic behavior is to handle 0 - 6 syscall arguments in registers during the call, and to recieve errno in a register if the carry flag is set on the processor when returning from kernel mode to user mode.

h3. errno

VSTa used error strings in kernel land and required that userland translate these strings to numbers. This was pretty complicated and really caused for some ugly code. The errno system has been revamped to behave as posix expects at this point, as no real benefit could be outlined for passing around strings.

h3. sys/param.h

Defines a curious collection of fairly non-platform specific macros, as well as a couple of platform specific defines. MIN(), MAX(), and powerof2() seem to be the ones glibc relies on the most from this file. By and large the majority of flat out defines look to be BSD psuedo-names for defines found in limits.h, and param.h includes limits.h in order to get most of its values.

h3. local_lim.h

Local platform specific limits.h data included by the top-level limits.h. Many values in here are actually interpretted as global minimum values that everything in the system must support. Some entries can have greater values at OS runtime, these values are discovered using sysconf() and pathconf(). Posix also defines POSIX prefixes for many of these values that declare the minimum value any value may have. Defining limits.h itself is not necessary, it is possible to insert the necessary information into locallim.h. By and large, glibc will actually try to use the limits.h supplied with the kernel headers. Something we need to fix. For now this file holds #define's that would not be found in the FMI/OS kernel's limits.h. Information such as PATHMAX, and OPENMAX.

h3. libc-lock.h

This is needed by glibc for its multi-threaded interfaces. The header effectively declares a common-glibc interface to a platform specific interface for all lock types. Quite a few lock types in here, each with an init, lock, unlock, finalize, and destroy function. Thread-specific storage interfaces are defined here as well. Might want to look into reworking the mutexthread interface to support some of these locks. For now this is a copy of the generic/libc-lock.h with some minor modifications to get around a few test conditions for IOMTSAFE_IO compile errors.

h3. errlist.c

This file constructs the errlist array used by glibc. The file itself is a direct copy of the gnu/errlist.c. Added -DERRLISTNOCOMPAT to the fmios/sysdeps/fmios/Makefile to inhibit errlist.c from attempting to include errlist-compat, as we don't really need to worry about any sort of odd backwards compatibility.

h2. Needed

Known issues about what needs to be done. It should be expected that new items will be added to this list as they are taken off. This is partly a result of glibc automagicly enabling other areas of its subsystem based on what a port supports.

h3. libio

Need to inform glibc of how to handle low-level libio interfaces. Not 100% where to do this yet unfortunately.

h3. crt1.o

Not 100% certain if the FMI/OS crt0.o will work for this. It also brings up the issue of what to do about boot servers. If everything is running 100% ELF it may not be a big deal.

h3. missing funcs

@IOacquirelock _IOreleaselock +libcfcntl +libcmessage +libcopen@

h3. missing stubs

@+gen_tempname +getcwd close fchmod rename sysconf unlink writev@

Also available in: HTML TXT