My 2 cents inline..... On Mon, 2009-05-11 at 02:03 -0700, Chih-Wei wrote: > On 5月10日, 上午4時08分, Yi Sun <[email protected]> wrote: > > There are a few things planed in my mind for next: > > 1. a mail list for Eeepc/X86 issues only > > I think android-porting list is just good for it. > Unless the topics are too hot, then we can fork a new list. A new list will allow people to look up information in a easier way. I have a few hundred e-mails flood in every day from different places, a separate list gives me a better choice to config my e-mail box to filter e-mails. Because the traffic in Android-porting is not too big at today, with/without a new e-mail list is not a very critical issue for me at the moment and we can postpone the discussion to the time when someone feels that we really need a new list for some reason. > > > 2. a git server for Eeepc/x86 platforms. > > Yes. Since the eee_701 project is almost dead, > I do think to re-invent a new one is better. > > Actually I'm planning to do that. But there are something I need to > figure out first. > Instead of eee_701, I plan to use a more generic name like eeepc (more > generic? please suggest). Good, people are all on the same line now. It is just about execution now :-) Actually, there may be differences among eeepcs (later we may have new wifi driver, new camera driver, new video card and new something else...). We may still end up with something like asus/eeepc/eee_bla. And we still need to cover the VM support as well. So, could we do two or three level structure (maybe you are talking about the same thing)? product_line_name/platform_name Like: eeepc/eee_701 eeepc/eee_1000e eeepc/generic If you don't have anything special for a platform, then use generic otherwise, create a special directory for the platform and put all special things in it.
Talking about emulator, to me emulator is based on CPU type. I think eventually, we may end up with: x86/eeeepc x86/emulator x86/hp x86/dell So if people can agree, then we can have 3 levels structure like: x86/eeepc/generic > And I hope to add some scripts to automatically detect the hardware > and load appropriate drivers or configurations. This is very important. I think. > The problem is, now it is not possible to use shell scripts in android > ramdisk(boot.img). > Current I'm considering two approaches: > 1. Add /system/bin/sh (+linker, all necessary libraries) to ramdisk. I > also have to add toolbox > that provides utilities for scripts. However, android toolbox lacks > some important utilities like sed and cut. > Without them it's hard to write useful scripts. > So I may have to add the necessary utilities to toolbox first. > 2. Add a prebuilt, static linked busybox with all utilities I need to > ramdisk. > The approach may be much easier, but I don't know if it is > acceptable by google. > I think Makefile may be able to solve your problem (if you only want to be able to load the right drivers). You can have makefile to automatically generate platform specific init.rc to do this. If you want to install drivers during run time, we maybe able to do it by extending system prop and vold. But in any case, adding a busybox is good idea, I always use it when I debug something. > > I may need your comments to move on. > > --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [email protected] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
