State and future of the project

[StefanS]

Dear group,

I would like to take your time for a little discussion and reflection about the project. For the impatient: tl;dr at the end.
Firstly, the current status. I understand that mainly Chih-Wei is working on generic issues&keeping the repo loosely up to date with AOSP. There are a couple of people like me who maintain device trees, and when encountering problems, dig into the core and try to fix specific stuff. However, most of the recent builds seem to work quite well in general and work is already being done on things which are not entirely essential, like the CrystalHD "project" and stuff like full VirtualBox support.
Right now we have a handful of device trees, which all produce slightly different ISOs with broader or more specific hardware support.

After having analyzed the way the hardware support is divided, I found there are very few "hard" separating factors. One is SSE3 support, which is officially required by Google, but can be circumvented for older devices (Pentium M being the prime example). The other one is libsensors/liblights of which currently only two "real" implementations exist: one uses the hdaps accelerometer and the others react on varying keypresses and simulate the device rotation.

Another problem is the inclusion of proprietary files (firmware) and apps (Google apps).

Now here are my ideas of how to improve the project status and provide a better and easier way forward for all of us, developers and users:

1. I want to suggest using AuFS or UnionFS to make it possible to update/enhance the base system with the use of "add-on" packs. This is similar to the "update.zip" mechanism of Android phone updates. It could be used to add custom firmwares or Google Apps via separate add-on SquashFS files even if the base system was not installed R/W, and if it was installed R/W the contents of that same add-on file could just be copied over the system. Then we can distribute "clean" Android base images, but still make it easy for the users to get their Wifi card working and have full Google Apps integration.
2. As for the sensors or other system-specific libraries, there are two options:
2a. modifying the library loader to "try" all available libraries
2b. using the "add-on" mechanism described in 1. to overload the libxxx.default.so
I'm not sure about what would be better, they both have advantages and disadvantages.

Conclusion: I think it's possible to reduce the number of offered downloadable images to exactly two: one with Atom optimizations requiring SSE3, and one built with the SSE3-less toolchain to run on older processor models.
It would require some work to detect all features for the different laptop models, but I think it should be pretty straightforward.

Motivation: Why do I want to consider this? In general, I'm of the optimizing kind and thus this idea feels natural to me. It would allow us to concentrate our efforts on providing fixes and solution to everyone using Android-x86. One often heard complaint is "my touchscreen is working on build X but my Wifi is working on build Y", and yes, having a common base image would allow us to address these issues and make all touchscreens and all Wifi adapters work in the common image. Also, it will require us to work on solutions which work in broader circumstances, not more specific ones. One example is my "tablet-mode" application which detects for convertible laptops if the device is in laptop or in tablet mode. When I initially wrote it, it was looking for a model-specific input device. But then I rewrote it with very little effort to just accept any device that will send a tablet_mode switch - so it will now work also on Dell, Asus and HP convertibles. I think this is the kind of solutions we should all be looking for. And finally, it will multiply the userbase and thus the test data. If anything doesn't work, we'll find out more quickly and with more people to test our fixes, and even more people will in the end benefit from it.

tl;dr: We should be working together more, and by combining all device trees into one single universal one, then we can use our resources more effectively and provide a better user experience for everyone.

Looking forward to your feedback!

Stefan

[zedascouves]

Sound good to me!

Duarte

[notandyet]

sounds sane

   would amd-brazos also be folded into this as it is an the atom-variant or are you speaking strictly intel? 

[StefanS]

On Sun, Mar 11, 2012 at 19:31, notandyet <andy1...@gmail.com> wrote:
> sounds sane
>    would amd-brazos also be folded into this as it is an the atom-variant or
> are you speaking strictly intel?

I would think that the Brazos/AMD platform would be supported by the
"full" build, because I'm not aware of any limitations - I think the
build is only Atom-optimized, but not strictly requiring an Atom CPU
to run on (at least the kernel can run on both).

I'm wondering if you should have a common kernel or if the kernel
should be Atom-optimized or non-optimized, too. AFAIK SSE3
instructions aren't used by the kernel at all, so it would only be a
difference of selecting another target CPU to optimize it for - and
the kernel doesn't really have a huge impact on performance anyway.

Stefan

> --
> You received this message because you are subscribed to the Google Groups
> "Android-x86" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/android-x86/-/bueMVoMCtWQJ.
>
> To post to this group, send email to andro...@googlegroups.com.
> To unsubscribe from this group, send email to
> android-x86...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/android-x86?hl=en.

[Stefan]

Hello,

this is a good idea, one (two) images for all devices! Then also no
special builds or device trees for my WeTab would be necessary anymore.

Beside of this a few "little" things could be important:

1. Include support for nVidia graphics drivers
2. Include support for Video-Acceleration and TV-Cards in general - the
cystal-HD-support could be a first step there, also ATI, nVidia and new
Intel chipset have video acceleration support which could be added by
this work
3. Add suport for hardware keyboard localisation

By the way, a few days ago I have read that the Linux Kernel guys
started over to again backpoprt Android Kernel changes to the official
Linux kernel, final target would be to have again only one kernel for
all. I think this would be the best solution of all as the Linux kernel
can support a lot of things where Android kernel guys are still working
on (for example by back porting Linux kernel features...).

This is what I have read about it:
http://www.golem.de/news/linux-weitere-android-patches-fuer-kernel-3-4-1203-90394.html
That is the project: https://lkml.org/lkml/2012/3/7/610

So maybe in future Android X86 could just use the official kernel.org
kernel???

Stefan

> --
> You received this message because you are subscribed to the Google
> Groups "Android-x86" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/android-x86/-/q1Wr1JqI2V8J.

[notandyet]

is this more in line with future 5.0 android direction?

 

and would it not be nice, to have something along the lines of 

make -j2 iso-img THIS-IS-THE-TARGET-MACHINE=y TARGET-ANDROID-X86=jb-5.0-rc1

and get firmware sensor and kernel config info and drivers directly from the machine instead :) 

this could save on downloads/syncing for all possible drivers and mismatching of drivers on various motherboards variations. 

after all if targeting a d945gclf2 for example, no need for radeon or nvida video drivers,

or on a brazos target do not need nvidia/intel gm3xxx video drivers.

oh well someone needs some zzzz's, not  and yet pillow calls:)

[Ron M]

The squashfs idea is great.
I started working on a recovery "3rd" stage boot loader for research purposes, but I think your approach is the way to go.

Also: could be nice to integrate into it an adb  extension for the remount option, and hmmm... possibly a USB connectivity? Just a thought..

Anyway - I hope that non-atom Intel processors are also kept in mind - I use some core i5 and core i7 for my work, and I intend to elaborate on it.

One more serious issue: full 64bit support.

Android can be an Amazing X-86 platform - not only for the mobile.

--
You received this message because you are subscribed to the Google Groups "Android-x86" group.

To view this discussion on the web visit https://groups.google.com/d/msg/android-x86/-/VxIUmivBvioJ.

[Dmitry Golubovsky]

Hi,

On Sunday, March 11, 2012 1:57:37 PM UTC-4, StefanS wrote:

> 1. I want to suggest using AuFS or UnionFS to make it possible to update/enhance the base system with the use of "add-on" packs. This is similar to the "update.zip"

   > mechanism of Android phone updates. It could be used to add custom firmwares or Google Apps via separate add-on SquashFS files even if the base system was not
   > installed R/W, and if it was installed R/W the contents of that same add-on file could just be copied over the system. Then we can distribute "clean" Android base images,
   > but still make it easy for the users to get their Wifi card working and have full Google Apps integration.

I like this idea. I'd also suggest adding full FUSE support (libfuse port does exist), and, on top of this, httpfs and sshfs. I have this stuff put together under
 https://gitorious.org/android-pc ; though it is based on Gingerbread, these parts would unlikely depend on Android version. Feel free to resue these patches..

Thanks

[Michael Rose]

Hello Stefan, et al.

I think those are wonderful ideas and are crucial to improving the adoption of Android on x86 based devices. We need a common installer with detection for various pieces of hardware. Also, some sort of auto update ability would also be very desirable.

I also wanted to add my support for 64 bit architectures as well. While it is not a necessity now, it will be in the future. At present Android has no need for more the 4GB of RAM, but going to a 64 bit now would allow for the use of additional memory which would be extremely useful when performing virtualization. Rather than have Android running in a VM under another host OS, at this point I think one could happily remain in the Android environment most of the time and only need to boot a regular desktop OS (Windows for instance) for the odd occasion. I would think it would make the most sense to boot directly into a 64 bit Android environment with support for additional memory and running virtual machines right from within the Android environment.

I would also love to see Coreboot brought into the process. Being able to skip past the whole BIOS boot up sequence by using Coreboot to launch a unified kernel and then start up Android. This would significantly cut down on the startup time and bring Android closer to having instant on capability on Coreboot supporting hardware.

Keep up the wonderful work. Thank you!

[StefanS]

Hello,

and thank you all for your feedback right now. Just now, I want to
emphasize an important distinction here: it's clear that improved
hardware support like nVidia graphics or 64bit (guess Google will have
an ace up it's sleeve here) or you-name-it will be always an ongoing
task. But my important point is not that, because it happens anyway
(or should, at least). So don't use this thread as a wishlist, because
it won't do any good - I think it's fairly well known what hardware is
not supported and what features _could_ enhance the project. The only
way forward about this is that people will get their hands dirty and
code.

My argument was that _any_ new feature or hardware supported should go
into a common device tree, so that IF someone implements nVidia
support or whatever, it will not be yet another ISO to download, but
just an updated version of _the_ "Android-x86" ISO.

Stefan

[rvdb]

Hi Stefan,

> My argument was that _any_ new feature or hardware supported should go
> into a common device tree, so that IF someone implements nVidia
> support or whatever, it will not be yet another ISO to download, but
> just an updated version of _the_ "Android-x86" ISO.

Yes, that is how I undestood the first mail, lets focus on that.
Please let me now If I still misunderstood things.

Anyone who has been working on a device tree, knows by now that 99.5%
of the tree stay's the same, and is the same for all tree's.
So how do we handle that, in an better way then a new iso for every
tree?

When I first started with the wetab tree, I used the tegav2 image,
and created additions to this image.
But someone with a bit of knowledge needed to replace files on a
installed image,
and from there create a new iso, for people without that knowlegde.
That worked oke, apart from kernel-modules, for a lot of people the
depmod was too difficult.

So what changes do we have now:
1. Kernel command line.
2. Additional kernel modules, we could live without, but it does make
live a lot
more easy.
(N.B. the "we could live without" is to make Chih-Wei happy :-)
If we have a "storage space" during initrd state, we could "add"
them, do a depmod
and load them, during initrd state.
3. Android hardware drivers, some we can handle with the "board" name,
so maybe
If we make this dynamical during boot, some problems are solved.
An other (more generic) solution would be to replace the *.defaul.*
modules.
Maybe during initrd state
4. adding system apk's, and other "configuration files" etc.
If we can find them during initrd, that should not be a problemn.

Again if I look at the wetab tree, I created a directory called
system_overlay.
During build time, this tree would go to /system. A nice concept, but
It would be much nicer, if that could be done during (the first?)
boot.

5. Initial user apk's.
Would be nice, but needs a lot of thinking.

So lets asume be have a "generic iso", how do we add the additions.
Maybe we need two seperate two situation's.
a. Additions to the inital boot.
b. Additions on an installed system.

Again I think there are two options.
a. Create a tool to change /system in the generic iso.
b. Find a storage space, where the additions are stored, and include a
way to add the stuff in there during boot.

ad a. This would solve only the initial boot, we still need a way to
add additions
afterwards.

So for now the best way for me seems to be:
1. Find a way to add storage visable during the initrd stage.
2. Find a way to include this in the generic iso for the first boot
3. Find a way to make storage available after the system is installed.
4. Change initrd to copy files from this storage to /system (needs r/w
system)
or use something like unionfs.
5. depmod and load of extra modules.
6. .....

A device tree is then a (relatively small) directory tree with all
specific stuff
that could be replace/enhanced without a complete new build.

Ofcourse we would need to solve a lot of problems, but then it is more
fun
to create a nice image then it is to use it :-)

>However, most of the recent builds seem to work quite well in general.
Absolutelly tru, altough we still need work on hw-accelerated 2D
graphics.
(video playback, hwcomposer ???).

>The other one is libsensors/liblights
>of which currently only two "real" implementations exist: one uses the
>hdaps accelerometer and the others react on varying keypresses and simulate
>the device rotation.

Don't forget the wetab accelerometer, there was a real implementation,
but we do not use it anymore, because the hardware is "broken" :-)

>This is similar to the "update.zip" mechanism of Android phone updates.

Hmm. I do not know how this works, but it sounds nice.

>2. As for the sensors or other system-specific libraries, there are two
options:
> 2a. modifying the library loader to "try" all available libraries
> 2b. using the "add-on" mechanism described in 1. to overload the
> libxxx.default.so

2a. Or set the name dynamically.
2b. seems to be more generic, this one would have my vote, I think.

To summarize, yes Stefan, I thing we could need a new setup for device
tree's.
It would require effort, I am willing to spend (the few time I can
spare) to help.
Lets hope more people will step in.

Greetings Rene

[Mike C]

Hello Stefan,

As far as my knowledge goes - I'm a simple user without programming skills or ability to build my own system - your plan sounds good. If (one of) your goal(s) is to enlarge the installed base of android-x86, an idiot (like me) proof way to install and update the system would be very desirable and the same idiot proof way to add support for specific hardware (like my still not working eGalax touchscreen) would be great. 

Creating a larger user base will in the end lead to more programmers being willing to dedicate time to further enhance android-x86. Currently, I feel, android-x86 is only suitable for computer literates, while the basic Android philosophy is to make computing easy for everybody and keep technicalities away from the crowd and pack things into simple user friendly installers. 

I think your plan helps fulfilling the Android philosophy for the X-86 platform. 

All the best,

Mike

Op zondag 11 maart 2012 18:57:37 UTC+1 schreef StefanS het volgende:

[Stefan]

Hello Stefan,

I understood your question like that. I just had added a few really
annoying points like keyboard-layout/nvidia just to not forget these.
But my impression is that you missed the key point of my message:

Let's have a look on these backports from Android Kernels into the
Standard Linux Kernel. Maybe even support these peoples in adding more
Android changes to the Standard Linux Kernel. AND then, not use anymore
an Android specific kernel, BUT the always latest Standard Linux Kernel
for building the Android X86. Transform Android X86 into just another
portable devices optimized Linux distribution which is running the Apps
from Android Market. Maybe then it also would be able in the future to
switch between Android User Interface and KDE/Gnome/... just on
requirement and without rebooting.

(That, except of the last sentence, is also the way Microsoft goes with
Windows on ARM (WOA))

Also the above problems with nVidia, Keyboard, Video-HW-Acceleration
would be solved immediately with the use of the standard Linux kernel.

Stefan

[crn]

From my point of view, currently the new versions of 4.0.3 works pretty good, so the point of making 1 unatended iso to install it could be a good step but I think that there are other points more importants like doing some kind of emulator for ARM apps, if we do that, many users will come here just to say that a lot of things are not working

If our greats programmers develotp that unatended install, it will call the atention to many lasts users with no knowledge of computing, so this group will be full of critics saying

[StefanS]

Hi Stefan,

On Mon, Mar 12, 2012 at 14:47, Stefan <matthaeu...@googlemail.com> wrote:
> Also the above problems with nVidia, Keyboard, Video-HW-Acceleration would
> be solved immediately with the use of the standard Linux kernel.

Well, actually, not at all, I'm afraid.

Not a single of those issues mentioned would be solved by using the
standard Linux kernel. For one, Android uses kernel extensions which
have not yet been accepted by the kernel maintainers. Have a look at
Xen and how long it took them to get even a minor subset of their
changes into the kernel, and you know what to expect.

nVidia - yes, kernel modules are necessary, but more important is the
Mesa part, so kernel doesn't help.
Keyboard locale - needs to be adressed in Android, possible, but just
no-one bothered yet. Kernel doesn't deal with it at all.
Video+HW-Acceleration, same issue. Yes, a kernel driver is often
needed, but if the already exist in the standard kernel it's a very
minor thing to backport them into the Android kernel. Much bigger
issues are to be dealt with in Android itself. Ask René if you like.

So - the kernel isn't the problem. In fact, the kernel is probably one
of our least problems, just because there is a mainline kernel to
borrow from. If you think that's not a good way to go, ask the
longterm kernel maintainers (2.4, 2.6.27, 2.6.32 etc.). They do this
all the time.

In fact, many people overestimate the role of the kernel. The kernel
just provides basic hardware support, so yes, nothing would work
without it. But once the kernel supports all your devices, you need to
make them work in the higher levels of the OS, which usually is much
more work. For example, the old wacom pens work on a serial interface.
You could probably use a 2.0 kernel and they work. But you need an
extra "converter" program to make Android recognize them as input
devices. Same goes for graphic cards: yes, the kernel needs to
initialize the PCI(e)/AGP device bus and maybe in recent kernels
provide some basic access features (KMS), but writing an OpenGLES
compatible driver for a graphics card is much more work.

I've run Linux distros on kernel versions one or two minor versions
higher or even lower than they were supposed to, and never encoutered
serious problems (e.g. running SuSE which came with 2.2 kernel on 2.6
kernel), and I know that on Android phones people also switch kernels
like their underwear, so we should just make sure the kernel works in
general for the devices we want to support, and concentrate on the
higher OS levels.

Also, on a more general note, I want to emphasize, that unlike Android
on phones, we're not heavily restricted in terms of space. My kernel
config has almost all modules enabled and they amount to only 23MB of
space, which is further reduced by squashfs compression, the kernel
itself is 2.4MB. The total image including all currently available
MESA drivers and kernel modules AND Google Apps is only 155MB, no-one
would care if it was 200MB. So, while building device-specific targets
may be reasonable for phones (e.g. my Milestone only has 155MB
internal storage), it's simply not needed for x86 computers, since
anything under 512MB storage is probably not even available on the
market.

Stefan

>
> Am 12.03.2012 09:11, schrieb StefanS:
>
>> Hello,
>>
>> and thank you all for your feedback right now. Just now, I want to
>> emphasize an important distinction here: it's clear that improved
>> hardware support like nVidia graphics or 64bit (guess Google will have
>> an ace up it's sleeve here) or you-name-it will be always an ongoing
>> task. But my important point is not that, because it happens anyway
>> (or should, at least). So don't use this thread as a wishlist, because
>> it won't do any good - I think it's fairly well known what hardware is
>> not supported and what features _could_ enhance the project. The only
>> way forward about this is that people will get their hands dirty and
>> code.
>>
>> My argument was that _any_ new feature or hardware supported should go
>> into a common device tree, so that IF someone implements nVidia
>> support or whatever, it will not be yet another ISO to download, but
>> just an updated version of _the_ "Android-x86" ISO.
>>
>> Stefan
>>
>

> --
> You received this message because you are subscribed to the Google Groups
> "Android-x86" group.

[StefanS]

Hi René,

On Monday, March 12, 2012 11:14:38 AM UTC+1, rvdb wrote:

So what changes do we have now:
1. Kernel command line.

Yes, indeed, although what do you really need? Also, I would even add an installer point where you can change certain command line parameters (noob-safe).
 

2. Additional kernel modules, we could live without, but it does make
live a lot
more easy.

Additional modules are so uncomplicated. Just have them all in the image, and do the modprobe'ing in the xxx_info script (detect_hardware).
 

3. Android hardware drivers, some we can handle with the "board" name,
so maybe

Well, we could set androidboot.hardware=xxx in the installer, but I don't think that's helpful.
 

4. adding system apk's, and other "configuration files" etc.
   If we can find them during initrd, that should not be a problemn.

5. Initial user apk's.
   Would be nice, but needs a lot of thinking.  

Again I think there are two options.

a. Create a tool to change /system in the generic iso.
b. Find a storage space, where the additions are stored, and include a
   way to add the stuff in there during boot.

 
That's what I meant, but I have the feeling you imagine it too complicated. Already the init system is looking for the system.img/system.sfs file and mounts this as /system. It is, I believe, trivial to add at this point a function that finds files called update-*.sfs which lay at the same place (or SD card or wherever) and do a unionfs/aufs mount with them _over_ the /system mount. This means that any file contained in the update files will appear instead of the original file. So the user can have an update file with maybe very new kernel modules and a newer _info script to load them, he can have a update-apps file containing the Google Apps and so on.

 

To summarize, yes Stefan, I thing we could need a new setup for device
tree's.
It would require effort, I am willing to spend (the few time I can
spare) to help.
Lets hope more people will step in.

And basically, we wouldn't have device trees anymore, only one. And maybe if there are too many developers (unlike now ;) ) we would then split some files so that changes can be made without interfering with other people.
 
Stefan

[Stefan]

See below, behind <<

-------- Original-Nachricht --------

Hi Stefan,

On Mon, Mar 12, 2012 at 14:47, Stefan<matthaeu...@googlemail.com> wrote:
> Also the above problems with nVidia, Keyboard, Video-HW-Acceleration would
> be solved immediately with the use of the standard Linux kernel.

Well, actually, not at all, I'm afraid.

Not a single of those issues mentioned would be solved by using the
standard Linux kernel. For one, Android uses kernel extensions which
have not yet been accepted by the kernel maintainers. Have a look at
Xen and how long it took them to get even a minor subset of their
changes into the kernel, and you know what to expect.

<< Then I think it would be a good task to work on this acceptance.

<< http://www.golem.de/news/linux-weitere-android-patches-fuer-kernel-3-4-1203-90394.html
<< https://lkml.org/lkml/2012/3/7/610
<< Get in touch with John Stultz from that site to accelerate this process. Invite him to join this group, etc...

nVidia - yes, kernel modules are necessary, but more important is the
Mesa part, so kernel doesn't help.

<< Agree for mesa, who is working on this?

Keyboard locale - needs to be adressed in Android, possible, but just
no-one bothered yet.

<< Not true, if I scroll back in the messages here on the list, I find many requests for hardware keyboard localisations

Kernel doesn't deal with it at all.

<< Ok, it's not kernel, but a standard Linux distribution has some mechanism for it, this thing should be integrated into Android. It should be combined with the language/virtual keyboqard setting.

Video+HW-Acceleration, same issue. Yes, a kernel driver is often
needed, but if the already exist in the standard kernel it's a very
minor thing to backport them into the Android kernel.

<< porting back and forward from one kernel to another might be an easy task, but it takes time you could work on other things. So why not unifying the kernel with the one from standard Linux.

Much bigger
issues are to be dealt with in Android itself. Ask Ren� if you like.

<< I have read his posts about this.

So - the kernel isn't the problem. In fact, the kernel is probably one
of our least problems, just because there is a mainline kernel to
borrow from. If you think that's not a good way to go, ask the
longterm kernel maintainers (2.4, 2.6.27, 2.6.32 etc.). They do this
all the time.

<< Anyhow, you are doing double work which already has been done by the Linux kernel guys. Or those guys woking on mesa, X and other things.

In fact, many people overestimate the role of the kernel. The kernel
just provides basic hardware support, so yes, nothing would work
without it. But once the kernel supports all your devices, you need to
make them work in the higher levels of the OS, which usually is much
more work. For example, the old wacom pens work on a serial interface.
You could probably use a 2.0 kernel and they work. But you need an
extra "converter" program to make Android recognize them as input
devices.

<< Then better working on this interface than always backporting things from one Kernel into another

Same goes for graphic cards: yes, the kernel needs to
initialize the PCI(e)/AGP device bus and maybe in recent kernels
provide some basic access features (KMS), but writing an OpenGLES
compatible driver for a graphics card is much more work.

<< I agree with OpenGLES. But, doesn't that already exists and only has to be converted to X86? Or is nVidia Tegra graphics so much different from Geforce line of graphics chipsets?

I've run Linux distros on kernel versions one or two minor versions
higher or even lower than they were supposed to, and never encoutered
serious problems (e.g. running SuSE which came with 2.2 kernel on 2.6
kernel), and I know that on Android phones people also switch kernels
like their underwear, so we should just make sure the kernel works in
general for the devices we want to support, and concentrate on the
higher OS levels.

<< Don't tell me too much about Kernel versions, etc... Ok, I wasn't working on the source codes, but I have been tester for new kernel modules for brand new PC hardware in one of my previous jobs a few years ago. I also was able to forward chipset documentations to some of the developers. For example there wouldn't have been any good working driver for SIS integrated graphics chipsets about 7/8 years back...

Also, on a more general note, I want to emphasize, that unlike Android
on phones, we're not heavily restricted in terms of space. My kernel
config has almost all modules enabled and they amount to only 23MB of
space, which is further reduced by squashfs compression, the kernel
itself is 2.4MB. The total image including all currently available
MESA drivers and kernel modules AND Google Apps is only 155MB, no-one
would care if it was 200MB. So, while building device-specific targets
may be reasonable for phones (e.g. my Milestone only has 155MB
internal storage), it's simply not needed for x86 computers, since
anything under 512MB storage is probably not even available on the
market.

<< I fully agree with you. My WeTab has 2 GB of memory, some here like to use a core i3/5/7 processor based laptop for Android, it was already running smooth and nice with one GB with Android X86 on my WeTab, and a 32 GB SSD is more than the most smartphones and ARM tablets are having - and I can buy a 120 GB SSD for it, give me five minutes to swap it over... So don't care on ten more firmware files, twenty more Wifi kernel modules, three different graphics drivers (Intel, AMD/ATI, nVidia) in the image, that does not care as long as the most Android Apps are happy with a file size of up to 50 MB.

Stefan

[rvdb]

Stefan(S),

> > 1. Kernel command line.
> Yes, indeed, although what do you really need?

Well, my device should not have a acpi_sleep.
So in general it might be usefull.

> Additional modules are so uncomplicated. Just have them all in the image,
> and do the modprobe'ing in the xxx_info script (detect_hardware).

Oke, but then we can not have conflicting modules.
Search for atk3k, in real kernel already a problem for a few years, on
different hardware.
I could live without it, but a possibility to overwrite a module,
would be nice.

> That's what I meant, but I have the feeling you imagine it too complicated.

As always :-(

> Already the init system is looking for the system.img/system.sfs file and
> mounts this as /system. It is, I believe, trivial to add at this point a
> function that finds files called update-*.sfs which lay at the same place
> (or SD card or wherever) and do a unionfs/aufs mount with them _over_ the
> /system mount. This means that any file contained in the update files will
> appear instead of the original file. So the user can have an update file
> with maybe very new kernel modules and a newer _info script to load them,
> he can have a update-apps file containing the Google Apps and so on.
>

Is you're idea to have all the "device-trees" IN the generic image?
I believe it would be helpfull if they are not (gapps).
A good update mechanism would also solve this.

> if there are too many developers (unlike now ;).
Yes,that will happen soon :-)

Greetings Rene.

[StefanS]

On Mar 12, 2012 5:01 PM, "rvdb" <rene.van....@gmail.com> wrote:
>
> Stefan(S),
>
> > > 1. Kernel command line.
> > Yes, indeed, although what do you really need?
> Well, my device should not have a acpi_sleep.
> So in general it might be usefull.

Actually, no devices need it anymore because these ACPI quirks are handled in the kernel since several kernel versions ago.

> > Additional modules are so uncomplicated. Just have them all in the image,
> > and do the modprobe'ing in the xxx_info script (detect_hardware).
> Oke, but then we can not have conflicting modules.
> Search for atk3k, in real kernel already a problem for a few years, on
> different hardware.
> I could live without it, but a possibility to overwrite a module,
> would be nice.

Yes, exactly what an update file could do. But you can just rename your module and modprobe it when needed.

>
> > That's what I meant, but I have the feeling you imagine it too complicated.
> As always :-(
>
> > Already the init system is looking for the system.img/system.sfs file and
> > mounts this as /system. It is, I believe, trivial to add at this point a
> > function that finds files called update-*.sfs which lay at the same place
> > (or SD card or wherever) and do a unionfs/aufs mount with them _over_ the
> > /system mount. This means that any file contained in the update files will
> > appear instead of the original file. So the user can have an update file
> > with maybe very new kernel modules and a newer _info script to load them,
> > he can have a update-apps file containing the Google Apps and so on.
> >
> Is you're idea to have all the "device-trees" IN the generic image?
> I believe it would be helpfull if they are not (gapps).

That's exactly the point! gapps would be an add-on. Look at the Cyanogenmod Wiki. They distribute "plain" images and offer gapps as a separately downloadable package.

Stefan
>
> Greetings Rene.

[Corvus]

From my point of wiew...

- We really need a way to release updates and not to need to fully reflash a new image with every update, but we need to do it carefully because sometimes /data can cause problems with updates. By example, if you have a image with market and release a update with new market, the old files in /data can broke market. So we need to a way to make a wipe of data launched by users and some other sripts. We need a recovery like installer. Maybe we can modify the actual installer to make some more task, not only install to hard disk, by example, detect versions, install updates, etc.

- About universal tree... i think it's doable, but this will broke the way android build images, that is not perfect, and we can do better for a bunch of devices, but this have some problems, like that can be a barrier for other developers with experience in arm devices, think about a Cyanogen developer that wants to try to compile Android X86 and waits for a similar way that they do with any android build... or think about the posibility that a new device needs a tweak that we dont think about and we cant do it because we dont have a specific tree to do it.

And the posibility to include the needed libs for specific devices in a update is ok, but how did you build it? you will need a specific device tree to do it, so you will need this tree anyway. 

So i think that our best try is to have a mixed enviroment, we have specific device trees for some devices that needs special tweaks and a generic device tree with all modules, configs, etc that can be together (I add Intel wifi support to Wetab with Atheros in the same image...). This generic will be bigger and possibly with less performace, but will run in almost all device. The problem with it is that for specific hardware it will not work (like 3G), but this tree can be a base for create a more specific tree.

Resuming:

We need a more fast way to release updates and a way to control that way this updates are done... we need a recovery-like installer. Maybe Anaconda (http://fedoraproject.org/wiki/Anaconda) or other linux installer can help us in this.

But i dont think we need a universal tree because it will cause more problems that helps us.

Corvus.

[Chih-Wei Huang]

Wow! A long but good discussion.
I even don't have time to read them all until now.
Thanks to all participants.

Basically speaking, I like StefanS's idea.
If the goal could be achieved, it does solve
some difficult problems we suffer now.

Personally I'm familiar with Aufs technology.
I did some projects with Aufs author before.
Actually I also considered to use it when we
started android-x86 project, but finally
I thought we don't need it, at least at that time.

Anyway, it's a good idea to do customization
by "overlay" some files via aufs.
Though there are still some unclear points
that need to be clarified.
Let me consider the possible infrastructure changes
(provided I have time :p)
If you already have some, please provide.

--
Chih-Wei
Android-x86 project
http://www.android-x86.org

[fuzzy7k]

As it has been hit on a few times, having an installer that can detect hardware and install packs according to vendor id, product id, or dmi string is key. The benefits I see are less space on the download server, and fewer options for the user to download. There is some developer unity there too, but it is already cake for one developer to import improvements that another developer has implemented. The downside I see is more developer overhead.

Updates are another issue. How do you prevent an update to the base system from overwriting a pack file, or how do you make the update system aware of what packs are installed.

There are answers to these issues but the work is in the details and there are a lot of details. This is a lot of work for a project without paid developers.

On Sunday, March 11, 2012 1:57:37 PM UTC-4, StefanS wrote: