On Wed, Jun 3, 2015 at 4:15 PM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
I created a patch on top of upstream binutils for a feature I need which should be universally useful as well. Now I have 3 questions for you:
- Does it look sane enough?
You added the option docs into the .section docs. It is certainly OK to talk about it here, but there is also a list of all options in the docs, and the new option needs to be documented here also. One could perhaps refer to the other. Otherwise, the patch looks OK, but I have little experience using macros, so I'm not sure if there might be a better way to do this. I'm also not sure how the other binutils maintainers would feel about the design. It would have to be discussed on the binutils mailing list.
- If so, could you integrate it in the Linaro release?
The normal toolchain process is that patches get added to our releases only if they are already upstream. Our releases are FSF releases plus patches backported from mainline, with no local changes except when absolutely unavoidable. I think that we'd rather delay a release so we can submit a patch upstream first than make a release on time with an extra non-FSF patch. So this needs to get into FSF binutils first, and then we need a business reason to backport it, e.g. a member explicitly asks us to backport it, or it fixes a bug that a member reported, or is needed by a major open source project.
- Would you be willing to promote it upstream?
We would need a business reason to promote it upstream, as above. Otherwise it would be a personal decision, and I don't know if there are any active binutils developers here that might be interested. It is probably best to just go through the normal binutils patch submission process. They tend to be pretty open to patches, and tend to accept anything that looks like it might be useful, unless there is already another way to do this making your patch redundant, or if your patch conflicts with some existing feature, etc.
Jim