On Mon, Jun 13, 2011 at 10:41 AM, Koen Kooi <k...@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 <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
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@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" _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
