Moving ports architectures to libc?

["Joseph S. Myers" <joseph at codesourcery dot com>]

Should we start moving ports architectures into libc (after 2.19 is 
released), with a view to eliminating the arbitrary distinction between 
the two sets of architectures (and reducing the number of ChangeLog files 
needing updating for global changes)?

It's already the case that it's generally preferred for patches to update 
all architectures if possible, with no distinction between libc and ports 
architectures, and only if the updates are non-mechanical and need 
architecture expertise or testing to list them on 
<https://sourceware.org/glibc/wiki/PortStatus> and leave them for the 
architecture maintainer.  We've also already moved the bits of the powerpc 
port that were in ports to libc.

I'd suggest the following for such moves:

* Moves only happen outside of release freeze time.

* The architecture maintainer does the move for their architecture and 
verifies that, for at least one configuration for the given architecture, 
the disassembly of the installed shared libraries is the same before and 
after the move.  (Thus, the port needs to build, unmodified, before the 
move, which I think would exclude am33 and hppa from moving at present.  
It does not need to be fully up to date with global changes - it may have 
entries in <https://sourceware.org/glibc/wiki/PortStatus> - although I 
certainly encourage maintainers to fix such issues either before or after 
the move.)

* Where the moved architecture #includes files from another ports 
architecture that hasn't already moved to libc, the direction of the 
#include should be changed before or as part of the move, so libc doesn't 
depend on the ports add-on being enabled.  Before moving any architecture 
using linux-generic, the linux-generic support must be moved.

* There is no change to how the ports architectures do certain things in 
separate files where libc architectures do them in files shared between 
architectures.  The approach used by ports architectures is the preferred 
approach, and libc architectures should be moved to use that approach.  A 
detailed list is in 
<https://sourceware.org/glibc/wiki/Development_Todo/Master>, starting 
"libc architectures should be more like ports architectures", and such 
changes are encouraged independent of any move of ports architectures to 
libc.

* Similarly, sysdeps/unix/sysv/linux/<arch>/nptl, the location used by 
ports architectures, is preferred to nptl/sysdeps/unix/sysv/linux/<arch>.  
(That preference is why we've put abilist files for libc architectures in 
such a directory, although existing sysdeps files for libc architectures 
haven't yet been moved - again, moving the existing files would make 
sense.)

* In libc, the main ChangeLog file is used.  The ChangeLog.<arch> files 
are left in ports and not changed further, with the aim that in the end 
the ports directory *only* contains old ChangeLog files.  (As suggested in 
<https://sourceware.org/ml/libc-alpha/2013-03/msg00608.html>, we might 
also consider eliminating some or all of the other subdirectory ChangeLog 
files and using the main ChangeLog for files in those subdirectories 
instead.)

* If we agree to move ports architectures to libc, then all future new 
architectures should be added directly to libc (following all the 
standards for ports architectures regarding use of sysdeps files not 
shared files), unless they are being added before linux-generic has been 
moved but depend on linux-generic.

* After a couple of release cycles, the architecture maintainer not having 
moved their port should be considered evidence that it is unmaintained and 
should be removed.

-- 
Joseph S. Myers
joseph@codesourcery.com