Re: [OE-core] [RFC] qemu* kernel configs
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): An update to this: devtmpfs: -# CONFIG_DEVTMPFS is not set +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y These are good options to have. I've recently turned them on for other kernels, for all arch. I'll be adding this in shortly. 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 +#
Re: [OE-core] [RFC] qemu* kernel configs
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 -#
[OE-core] [RFC] qemu* kernel configs
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. regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] qemu* kernel configs
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
