Re: Moving ports architectures to libc?

["Carlos O'Donell" <carlos at redhat dot com>]

On 01/21/2014 06:18 PM, Joseph S. Myers wrote:
> 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)?

Sounds good.

> 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.

OK.

> * 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.)

I disagree about hppa, I have patches, and I can do the move myself and
verify that it still builds afterwards?

> * 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.

Agreed.

> * 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.

Agreed.

> * 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.)

Agreed.

> * 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.)

Agreed.

> * 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.

Agreed.

> * 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.

Agreed.

Cheers,
Carlos.