On 12/08/2011 02:47 PM, Richard Purdie wrote: > On Thu, 2011-12-08 at 10:49 -0800, Darren Hart wrote: >> On 12/08/2011 06:31 AM, Bruce Ashfield wrote: >>> If you want to then modify the configuration slightly using either >>> in-tree or add on kernel >>> configuration fragments you can simply add a .cfg to the SCR_URI or set the >>> KERNEL_FEATURES variable, just like Darren did recently. >>> >>> KERNEL_FEATURES_append_fri2 += " cfg/smp.scc cfg/efi-ext.scc" >> >> >> This has the same original variable scope issue as before however. It >> would be nice to be able to do this: >> >> $ bitbake core-image-minimal >> $ bitbake core-image-minimal-debug >> >> The latter image would use the same machine, but it would build perf, >> add "debug" and other configurable options to "APPEND", and add a >> configurable set of KERNEL_FEATURES. We should also update the base >> kernel tools (non-Yocto) to use merge_config.sh so fragments can be used >> in those recipes as well. >> >> The problem I've run into here in the past has been that I cannot >> specify things like PREFERRED_PROVIDER in the image recipe. So, for >> example, to build RT, the current documented approach is to first add a >> PREFERRED_PROVIDER line to either local.conf or bblayers to select >> linux-yocto-rt and then to build core-image-rt which merely adds some >> relevant packages. It would be much preferable to be able to specify >> just an image target and not have to change your configuration because >> the image is the intuitive distinguishing factor for people. > > I'd like to give the bitbake perspective on this problem. > > PREFERRED_PROVIDER in images doesn't really make sense to bitbake. > Imagine you have: > > core-image-minimal setting PREFERRED_PROVIDER = "kernelA" and > core-image-minima-debug setting PREFERRED_PROVIDER = "kernelB". Both > would depend on "virtual/kernel". You then run: > > "bitbake core-image-minimal core-image-minimal-debug" > > What would you expect bitbake to do?
What I _think_ most people would expect it to do is to build each kernel and install the right one in each image. I understand this doesn't work with the way bitbake currently handles kernels, as you describe below. > The kernel is special in that doesn't really stage output that is reused > by other parts of the system but we have to consider the general case > where output such as libraries would end up in a shared sysroot. Even > then, the kernel does generate packages which it places in a machine > specific feed and the names don't reflect the different inputs, there is > one kernel-image package for example and in the above case it would be a > race on which one built last. The names not reflecting different inputs seems like it should be something we can address. I appreciate it isn't trivial, and probably stomps on some pretty core assumptions dealing with how we build images, but I believe it would be valuable to be able to build multiple kernel versions for a given machine. Many Linux distributions do this and I can see users of Yocto wanting to do the same with the distributions they build. > > Bitbake therefore takes PREFERRED_PROVIDER and VERSION decisions from > the core configuration (.conf / .inc / machine / distro / bitbake.conf / > base.bbclass). There is no easy solution to this problem, even recipe > specific sysroots would only get a part solution. Would this be something we should consider as a major feature development item for a future release? > Having said that, if you enable sstate checksums on the stamp files, you > will get a system that is *much* more responsive to change. With that > enabled you could: > > bitbake core-image-minimal > <realise you need debug enabled> > <edit some .conf which turns it on> > bitbake core-image-minimal > <have an image with debug enabled> > > The reason is that with the checksums on, bitbake can tell exactly what > changed, what it needs to rebuild and it will then do so. > > Cheers, > > Richard -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto