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

[Bruce Ashfield]

On Mon, Jun 13, 2011 at 9:27 AM, Koen Kooi <koen at dominion.thruhere.net> wrote:
>
> 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 don't think we need to go this far. The configuration as it currently stands
is not a golden standard, and in fact is already scheduled for some improvements
in the yocto 1.1 timeframe.

I'd consider this a suggestion for some new feature groups.

I wouldn't considering enabling groups of functionality that the community needs
for common higher level functional testing being extra or the kitchen
sink. If we
come up with feature groups, and name those groups, it is possible to
disable them
as well as enable them conditionally.

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

There's definitely two sides to this. Keeping the configuration tight
and minimal is
the embedded roots of these configurations. The problem with large
configurations
is the test matrix, which is something that we try to take seriously.
If there's an
explicitly enabled configuration, there's a known test for it and core
functionality that
can enable it (and for the record, I won't claim that this is 100%
followed, but that's
something we aim to improve).

Having named groups (where they names are the high level functionality) that
provide optional configuration that can be enabled, tends to hit the
middle ground
between these two issues. Users can see the name and grab onto the
functionality,
while the core set of configs stays clean and small.

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

Agreed. This goes back to the functionality to enable common use cases and
requirements. If you want to send suggestions via patches (config fragments
and SRC_URI updates) or just send lists of missing functionality and a mapping
to the higher level requirement, we can work together to enable what we need and
move the rest to optional features or other layers.

Cheers,

Bruce

>
> regards,
>
> Koen
>
> PS: RP won't like making kernel builds take an hour, so from that POV minimal configs are a feature ;)
> _______________________________________________
> 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"