maintainership of PEI code in BFD

[DJ Delorie]

>   DJ> Please discuss such topics on the binutils mailing list, not in
>   DJ> private mail.
> 
> Since you didn't change the reply-list to binutils, I won't do so
> either...

OK, I guess you missed the invitation, so I moved this to binutils.

>   DJ> Sadly, the only real solution to this is for target maintainers
>   DJ> (that would be you) to pay more attention to what's happening in
>   DJ> BFD-land.  Where were you when these changes were being
>   DJ> discussed a year ago?  Why did you wait so long to tell us you
>   DJ> had a problem?
> 
> Are you saying it's OK to break other people's code when they're not
> watching?

No, I'm saying that it happens regardless of how much we don't want it
to.

> As far as I can tell, the breakage was done intentionally.  This comes
> from peigen.c:
> 
>   /* FIXME: This file has various tests of POWERPC_LE_PE.  Those tests
>      worked when the code was in peicode.h, but no longer work now
>      that the code is in peigen.c.  PowerPC NT is said to be dead.  If
>      anybody wants to revive the code, you will have to figure out how
>      to handle those issues.  */

There were two targets, one dead.  Left with one valid PE target
(which is cpu-independent), making the code generic became OK.

> As does this comment:
> 
>   /* NOTE: it's strange to be including an architecture specific
>      header in what's supposed to be general (to PE/PEI) code.
>      However, that's where the definitions are, and they don't vary
>      per architecture within PE/PEI, so we get them from there.
>      FIXME: The lack of variance is an assumption which may prove to
>      be incorrect if new PE/PEI targets are created.  */
> 
> Anything claiming that it's OK to include an architecture specific
> file in a supposedly generic file is certain suspect (and as it turns
> out, just plain wrong in this particular instance).

The "generic" PE code is used for pe-i386, pe-sh, pe-arm, and pe-mips.
If it doesn't work for pe-ia64, perhaps what you need isn't pe?

>   DJ> We try not to break things, but as we're all volunteers, it's
>   DJ> hard to promise anything.
> 
> At least I'd expect the folks with CVS write access to try not to
> break things knowingly.  That's all I'm asking for.

"Knowingly" is the key.  How can we know it's broken without being
able to test it?

>   DJ> I don't think undoing a year's worth of work is going to be an
>   DJ> acceptable solution (especially since we just got pe-i386
>   DJ> working really nicely).
> 
> Why would moving peigen.c back into peicode.h break a year's worth of
> work?

I didn't say it would break it.  I just said that undoing something
that happened a year ago because someone *now* says its broken is
unacceptable.  We just got the i386 build stable and fully functional,
and cygwin and mingw depend on it staying that way.  If you need
something changed, the right procedure is to discuss it on the
binutils list, not privately ask that it be reverted.

>   DJ> Fixing peigen.c to be platform-independent would be acceptable -
>   DJ> perhaps you could volunteer to make it so?
> 
> I'm not the maintainer of the PEI code and I certainly do not know
> enough about PEI in general to propose such a solution.  If someone
> tells me what I need to do to get the EFI code back to working with
> the current frame work, I'll be happy to try to make time and adjust
> the EFI code accordingly.

Sorry, I know nothing about EFI, so I can't help you here.