| |||||||||||||
ABS: The guts of AndroidABS: The guts of AndroidPosted Apr 28, 2011 5:25 UTC (Thu) by swetland (subscriber, #63414)In reply to: ABS: The guts of Android by ikm Parent article: ABS: The guts of Android
Interesting. Some of this is fascinating speculation, but a lot of it is certainly on the money. Regarding some of not-quite-how-it-is pieces:
The lack of including sysv ipc and the use of the Binder actually have nothing (directly) to do with each other.
sysv ipc is avoided because it allows for resource leakage beyond the life of a process. For the same reason, a /tmp filesystem is avoided, instead ashmem is provided which can give you the equivalent of anonymous shareable regions (passable by fd) that you'd create by open/truncate/unlink without needing to worry about leaking there either.
The toolbox was never intended to be a full commandline environment replacement, just an absolute minimum for state inspection and debugging -- /data/local/{bin,lib,etc} exist to give you somewhere to install "unix commandline goodies" on a typical android system.
The selection of ext4 had nothing to do with SMP -- emmc devices are traditional block devices, not raw nand, and thus need a traditional filesystem on top of the block layer. There's no real way (or reason) to use yaffs2 on emmc devices -- ext4 gets the job done.
/etc does exist (typically a symlink to /system/etc) and is a bit of a dumping ground for random configuration files, sadly.
(Log in to post comments)
ABS: The guts of Android Posted Apr 28, 2011 13:53 UTC (Thu) by karim (subscriber, #114) [Link]
Hi Brian,
Thanks for taking the time to look at this, and for dotting the I's and crossing the T's. Ideally, it would have been great to have you with us then at the event (or anyone from the Android team for that matter.) This actually was one of Jake's earlier points regarding the ABS: http://lwn.net/Articles/439337/. If nothing else, JIT auto-correct would have been possible ;) Maybe next year ... ?
If my memory serves me right, I did mention something to the effect of SysV IPC being open to DOS issues, but your explanation makes the issue clearer for sure. My reading of the SysV IPC matter with regards to Android is based on the [aosp]/ndk/docs/system/libc/SYSV-IPC.html file.
Regarding ext4 and SMP/multi-core, that one actually comes straight from Google's own Ted T'so (original LWN story: http://lwn.net/Articles/421117/ and original blog post by Ted T'so on ext4 and Android: http://www.linuxfoundation.org/news-media/blogs/browse/20...). So, in all honesty, I'm confused on this one. Maybe ext4 doesn't have anything to do with SMP, but doesn't the choice of a block device (for which there exists a lot of multi-core-optimized filesystems) instead of a flash device (for which most filesystems are not typically optimized for multi-core) have something to do with the increasing use of multi-core?
To an extent, I guess this kind'a brings into focus the issue of Android's development model. It is in fact very hard to fully understand the decisions behind Android's design or any significant change from one AOSP version to the next because we (non-members of the Android dev team) are not privy to the conversations amongst Android's developers. That said, I fully understand and respect the business logic behind this and, most importantly, appreciate your personal effort (and that of other Android developers) in participating in the wider community on forums such as this one. However, it remains that so long as key design decisions are taken behind closed doors without the involvement of the wider set of platform developers who have aligned their work with Android, speculation and misunderstandings are bound to continue. I wish I had a solution for this, but I don't. I just think this issue needs to be put out there. And maybe we just need to live with it. After all, what you guys are doing is nothing short of amazing. So it's hard to fault anyone on this. At the end of the day, though, it would have been great if I (and others) would have had a mailing list archive to grep instead of having to look at the code and sometimes have to guess at why this or that is being done.
Thanks again for having taken a look at this and for your involvement. I hope the above makes some sense.
Karim
ABS: The guts of Android: ext4 vs yaffs2 Posted Apr 29, 2011 16:27 UTC (Fri) by csimmonds (subscriber, #3130) [Link]
I think the choice of file system is dependent on the storage technology: Android devices with raw NAND flash will continue to use yaffs2, I imagine, but those using eMMC, which is basically a micro SD card soldered on to the main board, have to use a "normal" file system. In that case, ext4 seems a reasonable choice. Coincidentally, ext4 is likely to be more multi-threaded than yaffs2. So, I don't think it is a straight yaffs2 vs ext4 debate, it is more a question of horses for courses.
ABS: The guts of Android: ext4 vs yaffs2 Posted Apr 29, 2011 16:48 UTC (Fri) by karim (subscriber, #114) [Link]
Agreed. I've never thought about this as an ext4 vs. yaffs2 thing. But I am wondering if the shift to emmc is due to multi-core (as one would conclude if Ted's line of thought is followed) or due to the fact that hardware manufacturers just wanted their customers to be able to use standard filesystems on their devices (or the customers asking for it.) In all likeliness, the decision was made by hardware design guys ...
nand to eMMC - pin counts Posted Apr 29, 2011 22:01 UTC (Fri) by pflugstad (subscriber, #224) [Link]
I believe it's about pin counts. Bare nand requires a lot of pins. eMMC is essentially a serial interface, with variable width data path (8 bit max). So by going with eMMC, you reduce your required pin counts, which equals cheaper boards.
ABS: The guts of Android Posted Apr 30, 2011 7:35 UTC (Sat) by swetland (subscriber, #63414) [Link]
Much respect to Ted, who is awesome, but he's definitely incorrect about SMP being a major reason for the ext4 decision. SMP is also not the driving force for eMMC storage device choice -- that's more of the usual cost/performance/density decision making typical to storage parts selection for embedded devices.
As far as making platform design decisions more visible, that is something that we do want to do, and we are also working to move more of the core platform development "out in the open" over time -- for example the SDK tools development now happens entirely against the git repositories on android.git.kernel.org.
More documentation, aimed at lower level platform developers, OEMs, and integrators is also something that we're working on, especially around the HAL modules and other points of integration with specific devices.
ABS: The guts of Android Posted Apr 30, 2011 13:46 UTC (Sat) by karim (subscriber, #114) [Link]
Very cool! Thanks.
|
|||||||||||||