On 04/10/2016 01:22, Gregory Szorc wrote: > https://dxr.mozilla.org/mozilla-central/search?q=gonk seems to > contradict your assertion that gonk is well-contained.
I thought that the analysis in my first post was sufficiently detailed but here's one with line numbers to get a more accurate idea: - All gonk references and code in the following directory will be removed entirely because it's needed only for B2G-specific APIs and those are already being removed. This means that the following top-level directories will be purged of all gonk-specific code: * accessible * addon-sdk * browser * caps * chrome * devtools * docshell * dom (save for a few lines in dom/media, see below) * embedding * extensions * hal (save for a single file) * image * intl * ipc * layout * memory * modules * mozglue * netwerk * parser * rdf * security * storage * testing * toolkit * tools * uriloader (not 100% sure, but it's 3 files anyway) * xpcom (what's being done could be handled externally from gecko) * xpfe What would remain is the following; first the actual code: * widget/gonk - roughly ~50K lines but would drop to ~40K once we drop suppport for older Android versions as well as APIs that have been removed * b2g ~20K lines which would also drop considerably due to the removal of the APIs, completely self-contained * dom/media ~4K lines, which would be cut down once camera & overlay support are removed as well as the phone-specific, non-standard video and audio formats. The rest of the code is mostly self-contained within gonk-specific files * gfx ~2K lines a significant amount of which are related to camera and screen recording code that can be removed * hal Only one file would be kept in hal/gonk of ~2K lines (which are likely to be reduced once support for non-standard APIs is removed). A handful of lines would remain in hal/Hal.cpp and hal/Hal.h but if we drop the process priority manager (which I would do) those would also go. ~10 lines in hal/linux/LinuxPower.cpp * media Less than 1K lines, some of which are shared with Fennec and some which can be easily removed (e.g. they were used only on certain devices/versions) Then the configuration bits * build - 10 lines shared with Fennec * config - One line, could be possibly removed * js - 2 lines * nsprpub - 7 lines * python - ~50 lines * xpcom All in all we're talking about less than ~70K lines which would likely drop to less than ~50K lines once we've removed all the non-standard APIs. Of these most are self-contained save for gfx, media and dom/media which are arguably the ones where there's more intermingling between gonk-specific code and the rest though it's only a handful of lines. > There are > literally references to gonk throughout the tree. Every reference that > isn't self-contained introduces cognitive dissonance when someone > encounters it. They have to consider the existence of gonk when reading > and changing the code. This makes changing code harder and undermines > the ability for Firefox/Gecko to "evolve quickly." Even the very > presence of unused, self-contained code (like gonk widgets) adds > overhead because it can make common operations like refactoring more > time consuming. And if someone breaks the code (because it isn't used) > and a bug gets filed to track that, now you've introduced overhead for > people to triage said bugs. These problems don't exist when the code > doesn't exist. That's why we should aggressively delete unused and > unsupported code. While I can relate to that this also discounts the advantage which we would have by retaining the code which is the ability to deploy gecko on Android-based devices directly. That's something that proved to be useful outside of the phone domain. Also we're talking about a tier 3 platform which means that if a refactoring breaks it, it will be up to the people that are involved with it to fix it. IIRC bugs for tier 3 platforms are not triaged either so that shouldn't be a problem. Besides there's unsupported code that's been living in our codebase for ages and nobody seemed to be bothered by it. Searching for references to long-defunct platforms such as Maemo, MeeGo or OS/2 still yields results in our codebase. Gabriele
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
