The aio interface adds substantial attack surface for a feature that's not being exposed by Android at all. It's unlikely that anyone is using the kernel feature directly either. This feature is rarely used even on servers. The glibc POSIX aio calls really use thread pools. The lack of widespread usage also means this is relatively poorly audited/tested. The kernel's aio rarely provides performance benefits over using a thread pool and is quite incomplete in terms of system call coverage along with having edge cases where blocking can occur. Part of the performance issue is the fact that it only supports direct io, not buffered io. The existing API is considered fundamentally flawed and it's unlikely it will be expanded, but rather replaced: https://marc.info/?l=linux-aio&m=145255815216051&w=2 Since ext4 encryption means no direct io support, kernel aio isn't even going to work properly on Android devices using file-based encryption. Change-Id: Iccc7cab4437791240817e6275a23e1d3f4a47f2d Signed-off-by: Daniel Micay <danielmicay@gmail.com> |
||
---|---|---|
.. | ||
android-base.cfg | ||
android-recommended.cfg | ||
README |
The files in this directory are meant to be used as a base for an Android kernel config. All devices should have the options in android-base.cfg enabled. While not mandatory, the options in android-recommended.cfg enable advanced Android features. Assuming you already have a minimalist defconfig for your device, a possible way to enable these options would be: ARCH=<arch> scripts/kconfig/merge_config.sh <path_to>/<device>_defconfig android/configs/android-base.cfg android/configs/android-recommended.cfg This will generate a .config that can then be used to save a new defconfig or compile a new kernel with Android features enabled. Because there is no tool to consistently generate these config fragments, lets keep them alphabetically sorted instead of random.