Hi, We're preparing documents for analyzing porting efforts of Firefox OS, and I'm writing this e-mail up to organize these thoughts and get input from everyone on various parts. Any feedback is welcomed.
We think that it could be roughly separated into three types: *1. Devices with Gonk, consisting of a Linux kernel and userspace hardware abstraction layer (HAL)* [1]. For these devices, all hardware-related backends should be ready and no porting effort should be taken. Here are the mapping of Gecko and Gonk components. Gecko | Gonk --------------------------------------------------------------------- Display | Gralloc HAL and HWC HAL Audio | OpenSL ES + AudioFlinger AudioSystem | HAL of Audio HW and Audio Policy Manager Wifi | dhcp client, dhcp server, tethering, wpa_supplicant, hostapd, DNS server(property_set) Bluetooth | bluez+dbus, bluedroid Sensor | Sensor HAL Mounter | vold Power | Power HAL Camera | Camera Service in MediaService Process RTSP | (*It links share libraries in Gonk) GPS | Geolocation HAL Backlight/LED | light HAL RIL | rild, netd, dhcpd Platform Decoder Module | MediaCodec External Media Framework | OpenMax (libstagefright) ResourceManager | WakeLock Low Memory Killer | Linux Kernel Configuration Memory Pressure notification | Linux Kernel Configuration Nuwa | pthread, libc *2. Devices with ARM/x86 architectures but no Gonk.* For these devices, porting efforts of all components listed in the above table should be taken into accounted. *3. Devices with CPU architectures which is neither ARM nor x86.* For these devices, porting above all components are necessary, and we need to put the following items on the radar: - Crash reporting (toolkit/crashreporter/google-breakpad) and stack walking (for assertion reporting/debugging, xpcom/base/nsStackWalk.cpp) [2] - JIT - All of the optimized assembly/architecture specific intrinsics spread throughout the tree including [2]: - Assembly for various media/graphics libraries (libjpeg, libvpx, etc) - Architecture specific SIMD intrinsics for various things (SSE2 based graphics operations, SSE2 based charset conversions, cairo, skia, thebes, etc) - Hard-Floating/Soft-Floating (Thanks Kyle Huey for providing the above information. ) Besides, we went through m-c code base quickly and found some inline assembly [3], and we're not sure if the functionalities of the following components are still working without these inline assembly. (If they are used for acceleration, the functionality should be fine but with poor performance. Or, the component might be broken due to the lack of the inline assembly.) Please help us point out the modules which might be risky and we can also put them on the radar. Thanks. - build/stlport/ - db/sqlite3 - gfx/qcms/transform.c: cpuid() - ipc/chromium/src/base - js/src - TraceLogging.cpp: rdtsc() - ctypes/libffi - devtools/vprof/vprof.cpp: readTimestampCounter() - vtune/ittnotify_config.h: __TBB_machine_fetchadd4() - media - libopus, libpng, libtheora, libvorbis, libvpx, libyuv, webrtc - memory - jemalloc, mozjemalloc - modules/freetype2 - nsprpub/pr - security - nss/lib/freebl, nss/lib/sqlite - sandbox/chromium/base - tools - jprof/stub/libmalloc.cpp - profiler/UnwinderThread2.cpp - xpcom - reflect/xptcall Thank you for your patience and cooperation. If you have any questions or concerns, don't hesitate to let me know. - Gina [1]https://developer.mozilla.org/en-US/Firefox_OS/Platform/Gonk [2]http://mxr.mozilla.org/mozilla-central/find?string=\.asm%24|\.s%24|SSE2&tree=mozilla-central&hint= [3]http://dxr.mozilla.org/mozilla-central/search?q=__asm__&redirect=true -- Gina Yeh Software Engineer Mozilla Taiwan _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
