[OE-core] [RFC] qemu* kernel configs

Bruce Ashfield bruce.ashfield at gmail.com
Mon Jun 13 12:54:23 UTC 2011


On Mon, Jun 13, 2011 at 8:10 AM, Koen Kooi <koen at dominion.thruhere.net> wrote:
> Hi,
>
> After finding the bug Scott was running into with systemd-image (no DEVTMPFS support) I have a closer look at the qemarm kernel config and it looks dated to me. If we want to have tools like udev, powertop, iotop, latencytop working we need to revisit the config. From a quick look I found the following items missing/incomplete:
>
> * devtmpfs + devtmpfs automounting. Recent udev versions require it
> * cgroups, systemd requires it
> * process accounting, *top uses it
> * fuse, gvfs requires it
> * autofs4, systemd works a lot better with it
>
> So what are people's thoughts on enabling the items that weren't set before and moving modules to built-in were > needed? And if it's wanted, does anyone have a quickstart on how these changes should be done properly? My 5 > minutes of google and 30 minutes of staring at the meta/ subdir didn't yield results.

Hi Koen,

The base configuration for the qemu* machines is kept as minimal as
possible by design. It is supposed to be used as a building block, not
cater to all the different image types we can throw at them by default.

So in this case, there may be some configs that we can turn on, but it
is not supposed to be a kitchen sink model, or have everything possible
we may need as a module module either. We can also create groups of
optional functionality, merge it into the kernel and enable it from the
various recipe appends. That way the base configuration does in
fact stay as the lowest common denominator, but other use cases can
enable what they need.

If you have changes required for other uses of qemu*, tossing them into
any file of the format <foo>.cfg and putting it in your SRC_URI will apply
those config fragments after the base configuration. Those changes
can then be sent and proposed as defaults, or kept in additional layers
that cater to particular image types and test scenarios.

Cheers,

Bruce

>
> regards,
>
> Koen
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"




More information about the Openembedded-core mailing list