This is the mail archive of the mailing list for the GCC 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: [RFC] A policy for supported ports and targets

Steven wrote:
These proposals are not to bash port maintainers.  It's just as much the
responsibility of other developers who want to move ahead with some
improvement to help out with updating the existing ports.  But again, it
should be the responsibility of the port maintainer to start this work.
After all, for many targets nobody but the port maintainer knows enough
about the internals of the port to work on it.

As the maintainer of one of the ports on your list, I'd like to add my perspective to the discussion. I think your proposals sound reasonable. I'm not sure if they will actually improve the situation very much, but I won't yell too loudly if the consensus is to adopt your new rules.

So, anyway, here is my perspective: I have a lot of other responsibilities besides maintaining the Xtensa port of GCC, and time is scarce. I usually end up allocating my time to whatever is most urgent. Updating the Xtensa port to use the new scheduler is a good example (and by the way, thanks very much for the work you did to update it!) I was planning to do this work myself, but the old scheduler was working just fine and the Xtensa pipeline is simple enough that I wasn't expecting the new scheduler to provide significantly better results. As you can guess, this project wasn't very high on my list of priorities. There are many other similar changes that I'd like to make as soon as I get a chance to work on them.

One thing that would help me a lot would be an easier way of finding out about changes that I need to make to keep the Xtensa port well-maintained. I spend a significant fraction of my time trying to keep up with this mailing list. Even so, I've had a hard time finding out what the current expectations are for GCC ports. Going back to the DFA scheduler example, if I had known that you were planning to remove it for the next release, I would have made sure to to do that work sooner. If you mentioned it on the mailing list, I guess I must have missed it. Since contributing the Xtensa port, I've found a number of things that I've needed to change to keep up with the latest standards for GCC ports. In almost every case, I stumbled across these things while looking at other ports, browsing ChangeLogs, etc. The backends.html matrix has been helpful, I guess. I'm not sure what to suggest to solve this problem. Informative subject lines in messages certainly helps (e.g., "old scheduler being removed for next release" would get my attention).

I think it would also be reasonable to push more work onto port maintainers. If someone wants to make an infrastructure change, I wouldn't mind if they sent me an email asking me to handle the Xtensa-specific portions. I might not be able to do the work immediately, and the Xtensa port may be temporarily broken, but that's probably acceptable for minor ports. I guess other port maintainers might disagree, but this seems like it might be a good way to balance the need to make infrastructure changes easier while still supporting lots of different ports.


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