Hello and introduction

["Jonathan S. Shapiro" <shap at eros-os dot org>]

I'm in the process of trying to bring up native-mode glibc for the
Coyotos OS (the successor to EROS). This is proving challenging for two
reasons:

  Coyotos isn't, and isn't intended to be, a POSIX OS.
  In addition, there are the usual porting issues that are generic
    to any port.

All of the issues in the second category (at least the ones we have hit
so far) are generic.

In order to avoid cluttering up the list with irrelevancies, I would
like to ask a high-level question about the intended scope of GLIBC.

Long ago, GLIBC supported a wider range of platforms. Over time these
decayed, and recently there are some people who have reported
significant difficulty getting relatively minor changes for non-UNIX
platforms integrated. More recently, certain coding conventions are
emerging that would make supporting some platforms (e.g. VMS) fairly
difficult.

I don't see any benefit to chewing up people's time and attention wihout
any purpose, which raises the following question:

  Is it a glibc design objective to support current non-POSIX platforms?

To clarify: from what we are seeing, most of the Coyotos-specific issue
is simply a matter of omitting some object files from the build if the
target platform doesn't use them. For example, Coyotos has absolutely no
use for the getmntent() family of calls. If there is already a way to do
this, we would simply like to use it. Otherwise, is it "fair game" to
propose a patch that would omit certain files from the build according
to the platform's needs **without** otherwise disrupting the existing
code or build process?

Obviously, we'ld like to see stuff integrated so that we don't have to
patch and re-patch. However, I am absolutely certain that the libc
maintainers have an overwhelming job already, and I don't want to make
that job harder.

shap