Op 13 jun 2011, om 15:57 heeft Bruce Ashfield het volgende geschreven: > On Mon, Jun 13, 2011 at 9:27 AM, Koen Kooi <k...@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 <k...@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 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@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
