LWN: Comments on "What’s New in Android: O Developer Preview 2"

What’s New in Android: O Developer Preview 2

dlang — Mon, 29 May 2017 19:24:21 +0000

If you didn't have nat, you would still need the connection tracking for the firewalling.

And if you are advocating connecting home networks directly to the Internet without any firewall you are out of date by several decades.

What’s New in Android: O Developer Preview 2

flussence — Sat, 27 May 2017 14:52:22 +0000

Using it under duress; there isn't a clueful ISP with IPv6 rollout plans in a hundred miles of here :(

What’s New in Android: O Developer Preview 2

bronson — Fri, 26 May 2017 00:37:05 +0000

So why not turn off NAT?

(if you're unable to, then maybe THAT's the problem?)

What’s New in Android: O Developer Preview 2

flussence — Thu, 25 May 2017 17:55:04 +0000

The reason we can't have nice routers is... NAT. Every outbound connection from every client needs a conntrack entry, and with browsers and OSes on every device constantly phoning home it adds up insanely fast.

My edge router has 16MB of RAM, and I've empirically determined through attempting to run an ipfs node it crashes when it reaches about 700 connections. With about a dozen active devices on the LAN, seeing it reset itself via watchdog is becoming an annoyingly regular event.
It used to be much worse than this, mind you — out of the box this thing barely ran at all, so I had to put wifi/DNS/DHCP on a separate PC.

What’s New in Android: O Developer Preview 2

zlynx — Tue, 23 May 2017 22:24:14 +0000

For routers, I think a large part of the code size increase in Linux relates to TCP/IP networking, routing and firewall. The data structures used for routing and in conntrack and netfilter are all designed for ease of use and speed, not size. TCP windows and associated buffers have gotten really big (even excluding buffer bloat, because a gigabit LAN transfer legitimately needs a big buffer). And there's various packet schedulers with their own buffers, buckets and hash tables.

For phones today I think the majority of code goes into fonts and graphics. Several different fonts have to be rendered and cached, and I'm not sure if they limit glyph generation to those used, or just do them all up front. Bitmaps are gigantic. A good looking app icon for Android is up to "xxxhdpi" at 640 DPI, 192x192 px. (Do they just continue to add 'x's, or is 640 DPI enough for everyone?)

While writing this I found https://medium.com/@romainguy/androids-font-renderer-c368... which is a very interesting bit about the Android font system.

And of course there's no push back on using RAM. Developers often end up using arrays of 64-bit integers for values 1-10 and don't even think about it.

What’s New in Android: O Developer Preview 2

muwlgr — Tue, 23 May 2017 20:35:46 +0000

in 1980s, 8MB of RAM were enough for heavy Fortran modeling
in 1990s, for a dialup-modem pool (and 96MB for heavy Photoshop)
in 2000s, 8MB were barely enough for an embedded system or a router
now, 1GB is barely enough for Linux+xorg+icewm+skype+xterm+seamonkey
poor that software "development" had gone that way...

What’s New in Android: O Developer Preview 2

flussence — Mon, 22 May 2017 23:48:03 +0000

It's depressing to see Google declare 1GB as the “crippled device needing special treatment” limit. Every mainstream OS these days is outpacing Moore's Law, and they're not doing anything revolutionary to justify it — in fact they're regressing rapidly. You don't need an 8-core 8GB supercomputer to make a GUI based entirely around flat filled rectangles (not even rounded ones!) and cooperative multitasking feel responsive. Your engineers just suck.

support prior Qualcomm and MediaTek SOC's

liam — Sat, 20 May 2017 06:07:43 +0000

The ambiguity of corepilot is part of the (marketing) annoyance regarding its status, but, afaict, it is hmp related patches. The issue is whether or not they've rebranded something that already was available, but with some small optimizations for their soc (the Incredular Scheduler, aka cfs with carefully chosen parameters), or made substantial changes to the scheduler and pm.

From p.5 of http://cdn-cw.mediatek.com/White%20Papers/MediaTek_CorePi...

"Based on open-source HMP technology derived from Linaro (www.linaro.org), CorePilot maximizes the performance and power-saving potential of heterogeneous computing with interactive power management, adaptive thermal management and advanced scheduler algorithms."

So, this seems like something they are claiming to have developed that is based off of work done with Linaro.
Looking at gpl compliance, ianal (which should be the default internet understanding, imho:) so I am not sure whether or not they meet the terms.

support prior Qualcomm and MediaTek SOC's

excors — Fri, 19 May 2017 11:18:03 +0000

I can't see much documentation of what CorePilot is - does it refer to something specific in the kernel, more than just a marketing term for a bunch of HMP scheduler kernel patches and hardware design choices?

MediaTek doesn't need to release source themselves since they're not releasing binaries (as far as I'm aware). The source needs to come from people like Google (who release binaries for Nexus/Pixel/etc devices) - e.g. https://android.googlesource.com/kernel/mediatek/+/androi... is a MediaTek kernel that describes SCHED_HMP_PLUS as being "Corepilot hmp enhancement", but never actually uses that config variable, though it does have a load of other changes in kernel/sched/ and drivers/misc/mediatek/sched/ etc (some seemingly from Linaro's HMP patches, some MTK-specific).

Sony publishes plenty of kernels too, e.g. https://developer.sonymobile.com/downloads/xperia-open-so... is from a recentish MediaTek device. That has some "#ifdef CONFIG_SCHED_HMP_PLUS" in kernel/sched/hmp.c that change the scheduler behaviour. As far as I can see, all the code is there; it doesn't rely on copyright-infringing prebuilt binary kernel modules or anything.

Samsung publishes lots at http://opensource.samsung.com/, though I don't think they use MediaTek chips much. Lots of other MediaTek customers are probably manufacturers who don't care about GPL as much as Google/Sony/Samsung/etc and don't release any source, but that's not really MediaTek's fault.

support prior Qualcomm and MediaTek SOC's

liam — Fri, 19 May 2017 09:11:54 +0000

When did mediatek open source corepilot?

support prior Qualcomm and MediaTek SOC's

excors — Thu, 18 May 2017 15:59:22 +0000

The recently-announced "Project Treble" (https://lwn.net/Articles/722612/) looks like exactly that - an attempt to improve the APIs used by vendor userspace libraries so they can remain compatible with multiple Android versions, with Android providing the necessary compatibility code.

> That explains why handset manufacturers can't just type "make" and expect to get a working operating system.

Well, sometimes it's not an awful lot more complicated than that if the SoC vendor provides a decent BSP (you just need to type "lunch" before "make"), but some of the build steps are simply copying binary blobs around rather than building everything from source. (Those blobs might be built from a separate source control system with a separate build system and toolchain etc, so they can be hard to rebuild even if the vendor does give you the source. Plus you probably don't have the expertise to easily understand the code well enough to modify it, or documentation of the hardware that it talks to.)

support prior Qualcomm and MediaTek SOC's

bucky — Thu, 18 May 2017 15:15:00 +0000

That explains why handset manufacturers can't just type "make" and expect to get a working operating system. But it brings up a whole bunch of other questions.

Why the game of "crack the whip" with APIs? If it's essential, why not a "compatibility" library that thunks the old calls into the new calls? The API changes seem to be the bad guy, here.

I don't expect this forum to speak up and answer my questions. I read about, and experience the upgrade difficulties, and I hear "business model" as the explanation. But I can't seem to get my head around it.

Whose voodoo doll do I construct and stick pins in?

support prior Qualcomm and MediaTek SOC's

excors — Thu, 18 May 2017 13:03:41 +0000

They aren't violating the kernel's GPL - they typically provide their kernel drivers as source to the device manufacturers, and responsible device manufacturers release the full kernel source when they ship devices. (Maybe not all companies do; but there are some that do care about legality, and that willingly choose Qualcomm and MediaTek chips.)

They also have a lot of proprietary userspace code, often provided to the device manufacturers as binary blobs. That's often what causes difficulties upgrading to new Android releases, because those blobs might depend on APIs that have changed in the new release and the device manufacturers can't fix it themselves even if they wanted to, and the SoC vendors are probably more interested in selling profitable new chips than spending significant engineering effort on old ones they've already sold. But that proprietary code doesn't contain or use any GPL, it mostly just links to Apache-licensed Android framework libraries, so there's no licensing violation.

support prior Qualcomm and MediaTek SOC's

mfuzzey — Thu, 18 May 2017 12:59:39 +0000

I'm pretty sure they do, for the kernel parts.

But there are userspace blob drivers (for the GPU for example) and those aren't covered by the GPL.

support prior Qualcomm and MediaTek SOC's

DOT — Thu, 18 May 2017 12:30:14 +0000

MediaTek and Qualcomm just need to stop violating the GPL and release source for their drivers.

support prior Qualcomm and MediaTek SOC's

johnjones — Thu, 18 May 2017 05:28:43 +0000

Honestly its frustrating that while people claim phones do not get updated to the latest security updates their is little to no action from MediaTek or Qualcomm to support their old SOC's

If they did so and got support from google then they would be able to leverage their engineering investments in old products for longer and more people would have less problems with malware plus google would be able to sell more advertisements securely...

e.g. you still see many "new" phones being sold with Qualcomm Snapdragon 410 ( Moto G4 Play )

allowing those users to update their environment from Android 6.0 or 5 to "go" would be a huge boon

plus this graph https://developer.android.com/about/dashboards/index.html shows version 4 and 5 are deployed (Live) more than any others this should be a core target !!

regards

John Jones