1678 2011-10-14 12:12:13 +0000 kernel usability scripts 2012-04-04 13:47:24 +0000 1 1 6 Yocto Project Subprojects Kernel kernel-tooling unspecified x86 Multiple RESOLVED FIXED (P2)(QA Testing Completed) Done Medium enhancement 1.2 M4 1610 1 tom.zanussi tom.zanussi dvhart jiajun.xu sgw song.liu yp.kernel.watcher yp.watcher --- --- --- oldest_to_newest 16880 0 tom.zanussi 2011-10-14 12:12:13 +0000 Here's a dump of my slides on this topic. Basically my idea was to have 3 scripts to cover the 3 most common use cases for dealing with the kernel in BSPs: - creating a new BSP - setting config items - patching the kernel It's become apparent that people have a hard time dealing with the kernel, and Yocto adds another level of confusion to that, with machine and meta branches in recipes, git, etc. Dealing with the kernel is a big part of dealing with BSPs Creating BSPs is also error-prone, and a lot of it boilerplate. So we should make it all easy if we can for users who just want to get Yocto running on their board. Create a script or wizard to start a BSP with. Allow it to take a few parameters: the name and architecture of the new machine, what it's based on e.g standard, base, preempt-rt, etc, and any others that make sense. This would create a meta-machine layer in userspace. It would also create and point to a local clone of the repo. Within that clone, it would create the machine branch. It would also create the necessary meta branch items. At this point everything is ready to go – the user can proceed to build an image. The other thing that BSP maintainers need to do a lot of is enable and disable config items. Assuming you know the config items to set, you should be able to simply have them added to the BSP, committed to the meta branch, and have a rebuild pick them up. The third common use case is applying a patch to the kernel. Again, assuming the patch is good, you should be able to add them to the machine branch, have them committed, and have a rebuild pick them up. Sometimes a combination of patch + config item is necessary, that can be done as a combination of the above. All of the above should be doable without knowing a thing about git, or the Yocto kernel or even about Yocto. Basically: I have this board, I have this config option that Google tells me enables the CDROM drive, I want to try that without having to read anything. Anything above and beyond that involves reading something or using the other Yocto tools like Hob, in case there's a need to add some userspace changes. Speaking of which, should it be designed to integrate with Hob in some way? Initial implementation would probably just be 3 command-line scripts e.g. makebsp, configbsp, patchbsp. I'm assuming Python would be the best choice, but could be done as shell scripts, etc. 17024 1 tom.zanussi 2011-11-01 09:01:43 +0000 Moving this to milestone 2, swapping with 1660 to keep the hardware-related BSP stuff together in the first milestone. 17903 2 jiajun.xu 2011-12-30 22:29:14 +0000 I think for the feature, QA needs to use these script to do BSP modify. We will design detailed cases after these scripts are finished. 18167 3 tom.zanussi 2012-01-16 06:51:01 +0000 Moved to M3 - this is a bigger job than originally planned but is on track for completion the first week of M3 or so. Here is a detailed description of what's being implemented: http://www.mail-archive.com/yocto@yoctoproject.org/msg03555.html 19221 4 tom.zanussi 2012-03-19 15:21:10 +0000 Developement is complete and version 2 has been submitted - all input from version 1 was addressed. This should be pulled into M4. 19638 5 tom.zanussi 2012-03-29 22:59:09 +0000 Included in 1.2 M4, poky commit: 5a6ded1355156557635004fdde2c01feec436be2 19854 6 jiajun.xu 2012-04-04 13:47:24 +0000 QA tested the yocto-bsp/kernel in 1.2 M4 RC1, it could work.