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

[Koen Kooi]

Op 13 jun 2011, om 14:54 heeft Bruce Ashfield het volgende geschreven:

> 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.

It sounds we need to remove the qemu machines from OE-core and replace them with more useful ones if we want people to actually test images with the machine present in OE-core. The current kernel config blocks me from merging a recent udev and systemd into oe-core since it can't be tested with only oe-core in bblayers.conf.

I've found minimalistic kernel configs a huge pain since you need to know the mapping between "userspace error X" and "CONFIG_SOMETHING=y", which most people don't know or want to know. With superset configs customers (and users) can tweak it till it breaks, instead of tweaking till it works.

I'm not saying the qemu kernel configs needs to have everything enabled, since they are emulated machines which simply cannot have various extras (PCI cards) or have a hard time using them (USB devices are a pain in qemu). But having 'basic' things like devtmpfs disabled is counterproductive as Scott and I found out.

regards,

Koen

PS: RP won't like making kernel builds take an hour, so from that POV minimal configs are a feature ;)