This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: What is glibc-ports?
On Thu, 19 Apr 2012, Roland McGrath wrote:
> > Anyway, if the generic mechanism isn't used by glibc it's for people
> > using it - people who wish to use it for out-of-tree ports - to keep
> > testing it and ensure it keeps working, rather than for it to be used
> > artificially for that purpose.
>
> In practice, that's just saying that it will bit-rot and not be fixed.
> People working on new ports are not usually experts on libc internals.
> They just bang away until they get something working. The purpose of the
> infrastructure is to let the libc experts worry about picayune libc
> infrastructure issues and leave the porters just to worry about their ports.
If we move all architectures directly into sysdeps in libc, anyone making
a new port intended for inclusion in glibc will be structuring it for
direct inclusion in libc's sysdeps directories, not as an add-on (they'll
need libc patches anyway, to elf.h if nothing else). Doing a port as an
add-on will be a niche way of configuring glibc, that will require
knowledge of how to create an add-on at all.
I don't think it's very different from other niche ways of configuring
glibc. Consider --enable-static-nss, as an example that has had recent
patches. We're happy to take patches for it, but it's not covered in
normal glibc testing in the course of development, so yes it does
sometimes break; it's up to those using it to test it and fix problems
when found (or if a regression were raised promptly after being caused,
I'd hope the author of the patch causing the regression would help with
the fix). We want to encourage contribution of ports to glibc, but I
don't think the case of port-in-add-on is particularly more important than
any of the other unusual ways to configure glibc.
> > I don't think this extra directory level is a good idea. [...]
>
> I'm ambivalent about it myself. But I do like the notion of something
> testing the infrastructure for add-on ports.
Whereas I think testing it is much like testing --enable-static-nss - nice
to have it tested, but primarily for users of the feature to test it.
> > I also think we should look at how appropriate the existing sysdeps
> > structure is.
>
> That may have some merit, but I think it would be better not to shake this
> all up very soon. Of course, it all depends on the details of concrete
> specific proposals.
I noted "none of this has a particularly high priority". I don't think
any merge of ports back into the libc repository is high priority either.
My inclination in this area is that is may be better for incremental
pieces to come first. Those include:
* Moving libc code to use sysdeps directories for cases using architecture
conditionals in generic code.
* Likewise (use sysdeps instead of a single directory containing files
named after target triplets / ABI names), for files in scripts/data/
(where add-ons use a data/ directory in the add-on).
* Likewise, for abilist/ data.
* Review individual files in sysdeps directories such as sysdeps/unix/ to
see if they are still used anywhere, and if so, where. I don't think
anything will use mkdir.c or rmdir.c in that directory (implementations
that call "mkdir" and "rmdir" programs - for the old sort of Unix where
those were privileged programs that manipulated filesystem structures
directly, predating mkdir and rmdir syscalls), for example, and the
recently discussed sysdeps/unix/getppid.S should also be unused. Each
file can be considered, and where unused removed, individually.
--
Joseph S. Myers
joseph@codesourcery.com