I agree with the 3 level structure for x86/eeepc/generic, etc.. But I think one main starting point will be needed which would be x86/generic . Just cause it seems like more than a few people are targeting x86 as a hardware platform.
Kind Regards. PS: has anyone hosted builds for installer.img and live-usb ? On Mon, May 11, 2009 at 10:07 AM, Yi Sun <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
