I asked in #gentoo-embedded on freenode, but I would like to pose this question to a wider auidence through the list.
What is the status of phone/tablet support? In specific, I am curious about: * Modern hardware options (especially those without a hardware keyboard) * Status of F/OSS drivers * Xorg touch support (multitouch, virtual keyboards, etcetera) * Desktop environments designed for multitouch in portage * Graphical applications (e.g. dialer, calendar, web browser, email client) * Reliable filesystem options for flash storage in small memory environments. I know that the KDE project has Plasma Mobile, which gives us both a desktop environment and many key graphical applications. However, I am not sure if much has been done to support it in Gentoo's packaging and I would like to hear about this: http://www.youtube.com/watch?v=auuQA0Q8qpM I realize that it is difficult to convey the sort of information that one wants on an open ended topic such as this, so I will try to lead by example by talking about filesystem options. First off, Linaro has some good summary: https://wiki.linaro.org/Flash%20memory Their summary consists entirely of log-based filesystems and CoW filesystems. It omits in-place filesystems such as ext4 and XFS. In-place filesystems really should not be appropriate for a phone or tablet because they are not designed to gracefully recover from unclean unmounts caused by kernel panics or power loss (e.g. dead battery, battery removal), although Android uses ext4 anyway. A notable exception from Linaro's list that I happen to maintain in the tree is the ZFSOnLinux driver. ZFS has many attributes that are desireable for phones, such as easy backup through incremental send/recv (easy on bandwidth and battery life), the ability to detect corrupt data (flash is not perfect), LZ4 compression (better throughput/latencies and less flash is need to store the amount data) and ARC for a better cache hit rate when your working set exceeds the amount of memory you have for cache (always true on phones). ZFSOnLinux is currently behind other CoW filesystems in support for phones/tablets. Upstream is gradually improving this and it should become a competitive option in the future. The main areas that pose problems are: 1. Efficient use of minimal memory. 1a. Long held objects in SLABs cripple reclaim efficiency by preventing mostly empty slabs from being reclaimed. On Solaris, some of the caches implement a move callback that allows for compaction, but Linux's SLAB implementation does not provide the option, ZoL's SLAB implementation does not implement it and it is not clear if it is possible to defragment the things on Linux that use it without modifications to the Linux kernel. Thankfully, nearly all of the memory used by SLABs is in the ZIO buffers, which will be replaced with page-based scatter-gather lists in the next release. That will go a long way to mitigating this. 1b. mmap() double caches between the ARC and the page cache. This has been done in OSv's ZFS driver and can be done in the ZFSOnLinux driver. It is currently blocked on 1a as it does not make sense to implement sooner, but it will be definitely be done. 2. 32-bit support (not an issue on 64-bit ARMv8 hardware, but ARMv8 is rare) 2a. Linux's kernel virtual memory allocator is crippled because the kernel enters an infinite loop when it runs out of address space set aside for kernel virtual memory. This is not a problem on 64-bit system swhere the amount set aside exceeds the amount any single image system in existence currently has, but it is a major problem on 32-bit. There is the further problem of a global spinlock being used and certain accoutning functions iterating a linked list of all virtual memory allocaitons, but this secondary has been mitigated mostly through SLAB allocation. The main use of kernel virtual memory is to avoid external fragmentation issues that come from allocting large buffers, especially the SLABs that are used to minimize the number of kernel virtual memory allocations that are done. The next release will implement scatter-gather lists that should bypass this on the ZIO bufers while the other consumers either have already been moved to kernel virtual memory or should be moved. 2b. There is no upstream test coverage on 32-bit and there are open issues involving 32-bit runtime failures. The project has gradually fixed 32-bit issues, but more work needs to be done here to make 32-bit as reliable as 64-bit. This will likely come after the solution to 2a makes 32-bit feasible enough to subject it to regular testing. 3. Tweaks for flash storage. 3a. We will gain discard support from the Illumos community in the next release, but the behavior of the hardware when discard is translated into the native command needs to be studied. On SATA, discard is mapped to ATA TRIM. The design of ATA TRIM is broken before SATA 3.1 where TRIM is an unqueued command that introduces arbitrary lags. Consequently, continuous discard will be off by default and the recommended way of doing discard will be to run a fstrim-like command on the zpool. Research will be needed to determine if the continuous discard is appropriate for NAND used in modern phones/tablets. 3b. We need to create pools with the correct alignment shift to set the flash page size to avoid read-modify-write overhead on pages. On modern SATA/SAS hard drives, we can read sector sizes from SMART data, but these are often wrong on flash drives, so we rely on a list of drive identifiers. I am not sure what we will have on phone hardware to determine the sector size. Many of these improvements are not of exclusive benefit to phones/tablets, so we will gain them out of work being done for traditional laptops, workstations, servers and clusters. I expect to see the improvements avaliable from upstream sometime in the next 12 months. That said, I would love to hear similar descriptions of where we stand in other areas with regard to mobile devices.
