This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: What is glibc-ports?
On Mon, 16 Apr 2012, Carlos O'Donell wrote:
> My take-away was that the distinction between glibc and glibc-ports
> seemed artificial and out-dated.
Yes, it is.
> During the presentation Roland and I argued that glibc-ports serves
> the very useful purpose of providing a generic add-ons mechanism for
> supporting machines, libraries like libdfp, etc. Having ARM in ports
> also meant that the generic mechanism worked for the most complicated
> case possible: supporting a new machine. Bottom-line was that we
> didn't want to loose the ports add-on mechanism (in fact nptl is also
> an add-on but not as complex).
I think NPTL is sufficient to show add-ons adding sysdeps directories do
work. 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.
> * Move glibc-ports back into glibc under ports/ so I can stop dealing
> with two repos.
>
> * Keep ports/ the way it is because the add-ons mechanism is very
> useful for future ports and libraries from 3rd parties.
>
> * Some day in the future we move all machines into ports/ leaving
> generic code outside of ports. If ports is good enough for ARM it's
> good enough for everything else, and using ports/ day-to-day will
> ensure it doesn't bit-rot.
I don't think this extra directory level is a good idea. Our source tree
paths (sysdeps/unix/sysv/linux/<arch>) are rather long already as-is, and
we already have "sysdeps" for architecture-specific and OS-specific code;
I think a split between sysdeps and ports/sysdeps on the basis that
something is "generic" and something isn't is undue complexity (and
likewise with a complete move of sysdeps).
So I'd rather just have all ports directly under sysdeps/ (and
nptl/sysdeps/) - but I'd also like existing libc architectures to look
more like ports by using files in sysdeps for various things that have
architecture conditionals in supposedly architecture-independent files.
I also think we should look at how appropriate the existing sysdeps
structure is. Is the division between sysdeps/generic, sysdeps/gnu,
sysdeps/posix really well-defined? What is the proper definition of the
systems for which sysdeps/gnu or sysdeps/posix is used and should some of
that code actually be completely outside sysdeps? What are the features
meant by the various sysdeps/unix directories? No system actually used
with glibc is really "Unix" at present. Old concepts of "System V" and
"BSD" are a lot less relevant to modern Unix-like systems than they were
when glibc was originally written.
That fits in with the generic question of Implies files. One idea Roland
mentioned in <http://sourceware.org/ml/libc-alpha/2012-04/msg00280.html>
was dropping implicit use of parent directories. If you don't use parent
directories, maybe a flatter structure would make sense. Have
sysdeps/linux for things depending on the Linux kernel, sysdeps/hurd for
things depending on Hurd. For anything else under sysdeps/unix, work out
whether there is some common feature of supported systems that it relates
to (looking probably at kFreeBSD/GNU as well as the systems supported
in-tree), and put it in a directory named for that feature if we think it
is genuinely still relevant to multiple supported systems but shouldn't go
outside sysdeps - or put it outside sysdeps if it now looks appropriate
for all systems likely to be supported by glibc.
I suspect quite a lot of sysdeps/unix (including sysdeps/unix/<arch>) at
least is actually not currently used by any port and so should be removed.
The same applies in sysdeps/mach (there's no vaguely functional current
Hurd port to any architecture other than x86, why are there mach/powerpc
and mach/hurd/powerpc directories there? bitrotten GCC support for other
architectures or Hurd was deprecated and removed).
The distinction between sysdeps/ieee754 and "not in sysdeps" isn't
wonderfully well-defined either (I think some code outside there does in
fact depend on IEEE floating point arithmetic), although it's better
defined than some such distinctions.
In summary: I think libc architectures should use sysdeps directories more
rather than conditionals in generic code; ports architectures should move
back in libc architectures directly in the normal sysdeps directories
rather than in a ports/ subdirectory (though I don't object to temporary
use of such a subdirectory in the course of a move as a way of reading in
the history through git tricks before the files are moved); it may well
make sense to look at what files in sysdeps are actually used, remove
unused files and rework the overall structure very carefully; and none of
this has a particularly high priority.
--
Joseph S. Myers
joseph@codesourcery.com