To merge or not: baseline ppc64el patches

[tpearson.raptor]

I'd like to open discussion on whether there might be willingness to merge some of the baseline ppc64el (OpenPOWER) support patches into Chromium.  I am making this request primary because there are a number of maintainers that have been spending years -- myself / Raptor included -- continually repatching downstream to enable Chromium on OpenPOWER for various Linux distributions, and we would like to streamline this work over the coming years.

All of the patches that I am proposing are largely self-contained (any ppc64el-specific code is guarded via ifdefs), in an effort to make the ppc64el code effectively invisible to the "standard" x86/ARM development process.  We are not asking for any assistance or build testing from Google or any of the Chromium development resources, and would be keeping the support up-to-date as needed using our own resources.

There still seems to be some unspecified resistance to allowing the merge, however.  For example, the sandbox changes at https://chromium-review.googlesource.com/c/chromium/src/+/3645995 only touch common code in order to extend the #ifdefs that already exist for other Linux architectures with a single new enablement string (ppc64el) alongside the existing amd64/arm/mips strings.

If we can keep the amount of common code -- and new #ifdefs -- to a bare minimum, what is the pathway to getting approval to being able to merge the patches?  Again, the main issue here is that we are wasting a lot of developer time over the years across multiple downstream maintainers, just to keep re-applying and slowly updating the same patch set that has proven itself in widespread deployment on POWER machines over past 4-5 years.

Thank you!

[Niccolò Belli]

I think this topic deserves an answer from Google. Countless maintainers have spent their time forward porting this: Timothy Pearson does the heavy lifting on his ppa, Georgy Yakovlev and Stephan Hartmann co-maintain their own patchset for Gentoo, I maintain my own on the PF4Public overlay because sometimes they lack the time and I don't have write access to Gentoo's main repo, Void has its own patchset which only supports 4K page sizes and the list goes on.
Sooner or later Chromium is going to be forced to support 16K page sizes on M1 chips anyway so some ppc64el-specific code guarded via ifdefs is not the end of the world.

An honest answer, I don't ask much from a company who's motto was "don't be evil".

Thanks,

Niccolo' Belli (darkbasic)

[Andres Salomon]

Hi,

I think it's also worth asking whether Google would accept some of
these patches in ways that are not ppc64-specific. In other words, code
that cleans stuff up as part of a ppc64 patch set that maintainers
*don't immediately reject because they see "ppc64 support" in the title
or description*.

For example, the patch that Timothy proposed
(https://chromium-review.googlesource.com/c/chromium/src/+/3645995)
could be reworked to make the gn config easier to read and maintain.
Here's the non-modified code:



# The seccomp-bpf sandbox is only supported on six architectures
# currently.
# Do not disable seccomp_bpf anywhere without talking to
# secu...@chromium.org!
use_seccomp_bpf = (is_linux || is_chromeos || is_android) &&
(current_cpu == "x86" || current_cpu == "x64" ||
current_cpu == "arm" || current_cpu == "arm64" ||
current_cpu == "mipsel" || current_cpu == "mips64el")


I don't know how many architectures chromium officially supports, but I
suspect that those six are most or even all of them. This could be
changed to simply 'use_seccomp_bpf = (is_linux || is_chromeos ||
is_android)' if those six are all of the officially supported cpu
architectures; and if not, the exceptions being manually listed
('use_seccomp_bpf = (is_linux || is_chromeos || is_android) &&
(current_cpu != "s390x"'). This would resolve ppc64's issue as well,
obviating the need for that specific patch.

The question about whether ppc64-specific patches will be accepted
should also be answered, regardless of my point about a subset of these
patches.

Thanks,
Andres

On Mon, Jun 6, 2022 at 00:20, Niccolò Belli <niccol...@gmail.com>
wrote:

> --
> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
> ---
> You received this message because you are subscribed to a topic in
> the Google Groups "Chromium-dev" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/chromium.org/d/topic/chromium-dev/z5qbhoV-fNU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> chromium-dev...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/e8cb5b1c-c52f-4dd7-a1ce-233f15c4de96n%40chromium.org.

[Daniel Cheng]

We recently clarified the policy for patches that propose adding support for new platforms/ports that aren't supported by default in Chrome: https://chromium.googlesource.com/chromium/src/+/main/docs/contributing.md#:~:text=Code%20in%20the%20Chromium%20project%20should%20be%20in%20service%20of%20other%20code%20in%20the%20Chromium%20project

(Apparently, we had another pre-existing page in https://chromium.googlesource.com/chromium/src/+/main/docs/new_port_policy.md that I didn't know about until today; we should probably try to merge these two or have them cross-reference each other at least)

Daniel

You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/JDJ2DR.DTZFCRM9QJVB3%40queued.net.