For historical reasons, which may sound awful, but which stem from the Android's team strong belief that they should never break userspace (as seen from Android Applications' POV), even as the system evolves, things like /sdcard access are emulated using a FUSE interface, and then when that ran into performance limitations, some of the Android handset vendors have been trying to use a wrapfs based "solution" instead. The wrapfs solution is ugly, fragile, and will probably never make it upstream. The original problem comes from the fact /sdcard was a FAT file system, which meant that it had case insensitive lookups and it didn't have Unix permission semantics. The actual storage of the /sdcard now lives on a f2fs or ext4 partition, and and the original "FAT-ness" of /sdcard is simulated via a FUSE or a wrapfs layer. Worse, in newer versions of Android, the FUSE layer was used to implement Android application permission (which are essentially dynamic capalities which are granted when the user is asked whether or not to allow the application to have access to the user's photos, external storage, etc.), at least as they relate to storage. I'd like to talk about how we might be able to provide something maintainable from an upstream perspective that can provide the functionality which the Android system needs to offer to its applications. We've talked about trying to solve case insensitive lookups in the kernel before; that's fairly straightforward, especially since the FUSE implementations and wrapfs implementations I've seen only do ASCII case folding and completely punt on the Unicode aspect of I18N. But I think it should be possible to provide the other requirements of the Android storage semantics with minimal changes to the VFS layer, as well as using more standard tools in the upstream kernel developers' toolbox, such as a stackable LSM for the application-level permissions handling. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
