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

Tue Jun 14 15:13:15 UTC 2011

On Mon, Jun 13, 2011 at 10:41 AM, Koen Kooi <koen at dominion.thruhere.net> wrote:
>
> Op 13 jun 2011, om 15:57 heeft Bruce Ashfield het volgende geschreven:
>
>> 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.
>
> The changes I made are (diffing the result from extract-ikconfig):
>
> devtmpfs:
>
> -# CONFIG_DEVTMPFS is not set
> +CONFIG_DEVTMPFS=y
> +CONFIG_DEVTMPFS_MOUNT=y
>
> cgroups:
>
> -# CONFIG_CGROUPS is not set
> -# CONFIG_NAMESPACES is not set
> +CONFIG_CGROUPS=y
> +CONFIG_CGROUP_DEBUG=y
> +CONFIG_CGROUP_NS=y
> +CONFIG_CGROUP_FREEZER=y
> +CONFIG_CGROUP_DEVICE=y
> +CONFIG_CPUSETS=y
> +# CONFIG_PROC_PID_CPUSET is not set
> +CONFIG_CGROUP_CPUACCT=y
> +CONFIG_RESOURCE_COUNTERS=y
> +CONFIG_CGROUP_MEM_RES_CTLR=y
> +CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y
> +CONFIG_CGROUP_MEM_RES_CTLR_SWAP_ENABLED=y
> +CONFIG_CGROUP_SCHED=y
> +CONFIG_FAIR_GROUP_SCHED=y
> +# CONFIG_RT_GROUP_SCHED is not set
> +CONFIG_BLK_CGROUP=y
> +# CONFIG_DEBUG_BLK_CGROUP is not set
> +CONFIG_NAMESPACES=y
> +CONFIG_UTS_NS=y
> +CONFIG_IPC_NS=y
> +CONFIG_USER_NS=y
> +CONFIG_PID_NS=y
> +CONFIG_NET_NS=y
> -# CONFIG_FREEZER is not set
> +CONFIG_FREEZER=y
>
> Fuse/cuse:
>
> -# CONFIG_FUSE_FS is not set
> +CONFIG_FUSE_FS=y
> +CONFIG_CUSE=y
>
> taskstats:
>
> -# CONFIG_TASKSTATS is not set
> +CONFIG_TASKSTATS=y
> +CONFIG_TASK_DELAY_ACCT=y
> +CONFIG_TASK_XACCT=y
> +CONFIG_TASK_IO_ACCOUNTING=y
>
> Autofs:
>
> -CONFIG_AUTOFS4_FS=m
> +CONFIG_AUTOFS4_FS=y
>
> So of those change I would group them as:
>
> needed: devtmpfs, cgroups
> nice to have, but not critical: taskstats
> nice to have as module, but not critical: fuse/cuse
> nice to have as builtin, but fine as module: autofs

Thanks for the breakdown, it definitely helps. Now that I've got some
3.0-rcX items done, and recipe renaming behind me, I'll have a look
at these and see how best to incorporate the configs.

Cheers,

Bruce

>
> I haven't touched the blockdev or netdev cgroup throttling since I have no use for that yet. I can now boot systemd-GNOME in qemu-arm and have IO numbers in htop, so my itches have been scratched with the above.
>
> 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"