This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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]

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


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