* Kernel features @ 2014-09-07 8:51 Ilya Dmitrichenko 2014-09-07 14:17 ` Bruce Ashfield 0 siblings, 1 reply; 7+ messages in thread From: Ilya Dmitrichenko @ 2014-09-07 8:51 UTC (permalink / raw) To: yocto Today I have spent quite a while trying to figure how KERNEL_FEATURES works and why some of the things I pass in my configuration fragment are not getting enabled. It turned out that some of the options no longer existed and some had been renamed. The question is really why would this not get detected by kernel_configcheck or any other step? I'm guessing this might be the case of how kconfig works, perhaps... So I wonder whether anyone have looked into how we could actually get the feature dependency graph from kconfig to bitbake or at least some sort of helper tool? Perhaps parsing kconfig manifests in Python would be a starting point... Cheers, -- Ilya ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Kernel features 2014-09-07 8:51 Kernel features Ilya Dmitrichenko @ 2014-09-07 14:17 ` Bruce Ashfield 2014-09-08 5:50 ` Ilya Dmitrichenko 0 siblings, 1 reply; 7+ messages in thread From: Bruce Ashfield @ 2014-09-07 14:17 UTC (permalink / raw) To: Ilya Dmitrichenko, yocto On 2014-09-07, 4:51 AM, Ilya Dmitrichenko wrote: > Today I have spent quite a while trying to figure how KERNEL_FEATURES > works and why some of the things I pass in my configuration fragment > are not getting enabled. > > It turned out that some of the options no longer existed and some had > been renamed. Do you have an example ? We try and not rename or remove public facing configuration fragments, and hide the changing CONFIG_* values behind the fragment names. > > The question is really why would this not get detected by > kernel_configcheck or any other step? > > I'm guessing this might be the case of how kconfig works, perhaps... > So I wonder whether anyone have looked into how we could actually get > the feature dependency graph from kconfig to bitbake or at least some > sort of helper tool? Perhaps parsing kconfig manifests in Python would > be a starting point... There have been many efforts are changing, writing and processing Kconfig constructs in other languages .. they all end up being pretty much a re-implementation of Kconfig, and hence a big effort that needs to be continuously maintained over time .. also a big effort. But maybe I'm not quite understanding your question, if you can send along an example, that might help. Cheers, Bruce > > Cheers, > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Kernel features 2014-09-07 14:17 ` Bruce Ashfield @ 2014-09-08 5:50 ` Ilya Dmitrichenko 2014-09-08 12:14 ` Bruce Ashfield 0 siblings, 1 reply; 7+ messages in thread From: Ilya Dmitrichenko @ 2014-09-08 5:50 UTC (permalink / raw) To: Bruce Ashfield; +Cc: yocto Hi Bruce, On 7 September 2014 15:17, Bruce Ashfield <bruce.ashfield@windriver.com> wrote: > On 2014-09-07, 4:51 AM, Ilya Dmitrichenko wrote: >> >> Today I have spent quite a while trying to figure how KERNEL_FEATURES >> works and why some of the things I pass in my configuration fragment >> are not getting enabled. >> >> It turned out that some of the options no longer existed and some had >> been renamed. > > > Do you have an example ? We try and not rename or remove public facing > configuration fragments, and hide the changing CONFIG_* values behind > the fragment names. Here is what I was doing first: CONFIG_SND_OMAP_SOC=n CONFIG_SND_OMAP_SOC_MCBSP=n CONFIG_SND_OMAP_SOC_OMAP_TWL4030=n CONFIG_SND_SOC_TWL4030=n CONFIG_SND_AM335X_SOC_EVM=m CONFIG_SND_AM33XX_SOC=m CONFIG_SND_DAVINCI_SOC_MCASP=m CONFIG_SND_HRTIMER=m This is resulted in disabled options propagating as expected and CONFIG_SND_HRTIMER worked as well. The rest, however didn't. It turned out that basically CONFIG_SND_AM335X_SOC_EVM is misspelled and should be called CONFIG_SND_AM33XX_SOC_EVM. I think there must be a way to verify whether this existed or not. It then also turned out that CONFIG_SND_AM335X_SOC_EVM depends on CONFIG_SND_DAVINCI_SOC, and I had to enable that one and ensure it comes first. This is a working set: CONFIG_SND_OMAP_SOC=m CONFIG_SND_OMAP_SOC_MCBSP=m CONFIG_SND_OMAP_SOC_OMAP_TWL4030=m CONFIG_SND_SOC_TWL4030=m CONFIG_SND_DAVINCI_SOC=m CONFIG_SND_AM33XX_SOC_EVM=m CONFIG_SND_DAVINCI_SOC_MCASP=m CONFIG_SND_HRTIMER=m >> The question is really why would this not get detected by >> kernel_configcheck or any other step? >> >> I'm guessing this might be the case of how kconfig works, perhaps... >> So I wonder whether anyone have looked into how we could actually get >> the feature dependency graph from kconfig to bitbake or at least some >> sort of helper tool? Perhaps parsing kconfig manifests in Python would >> be a starting point... > > > There have been many efforts are changing, writing and processing > Kconfig constructs in other languages .. they all end up being > pretty much a re-implementation of Kconfig, and hence a big effort > that needs to be continuously maintained over time .. also a big > effort. I basically think that we could do something better then blindly throwing a set of options without verifying it. The reason I mentioned Python was that I though of sharing Kconfig's dependency graph with bitbake and thereby detecting errors like the above. As a user, this is what I'd love to see: Error: The Kconfig option CONFIG_SND_AM335X_SOC_EVM that you have specified doesn't exist. (Did you mean CONFIG_SND_AM33XX_SOC_EVM?) Error: The Kconfig option CONFIG_SND_AM33XX_SOC that you have specified doesn't exist. (Nothing similar exists) Warning: The Kconfig option CONFIG_SND_DAVINCI_SOC_MCASP that you have specified depends on CONFIG_SND_DAVINCI_SOC. I will enable CONFIG_SND_DAVINCI_SOC as a module for you. Hope this makes more sense. Cheers, -- Ilya ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Kernel features 2014-09-08 5:50 ` Ilya Dmitrichenko @ 2014-09-08 12:14 ` Bruce Ashfield 2014-09-08 12:31 ` Include PaX / GRSecurity Jens Lucius [not found] ` <CAPhDKbH3sj49qfuBnKY-JvD2AGarFpx1PnSOij67Uvr3gABeTg@mail.gmail.com> 0 siblings, 2 replies; 7+ messages in thread From: Bruce Ashfield @ 2014-09-08 12:14 UTC (permalink / raw) To: Ilya Dmitrichenko; +Cc: yocto On 2014-09-08, 1:50 AM, Ilya Dmitrichenko wrote: > Hi Bruce, > > On 7 September 2014 15:17, Bruce Ashfield <bruce.ashfield@windriver.com> wrote: >> On 2014-09-07, 4:51 AM, Ilya Dmitrichenko wrote: >>> >>> Today I have spent quite a while trying to figure how KERNEL_FEATURES >>> works and why some of the things I pass in my configuration fragment >>> are not getting enabled. >>> >>> It turned out that some of the options no longer existed and some had >>> been renamed. >> >> >> Do you have an example ? We try and not rename or remove public facing >> configuration fragments, and hide the changing CONFIG_* values behind >> the fragment names. > > Here is what I was doing first: > > CONFIG_SND_OMAP_SOC=n > CONFIG_SND_OMAP_SOC_MCBSP=n > CONFIG_SND_OMAP_SOC_OMAP_TWL4030=n > CONFIG_SND_SOC_TWL4030=n > CONFIG_SND_AM335X_SOC_EVM=m > CONFIG_SND_AM33XX_SOC=m > CONFIG_SND_DAVINCI_SOC_MCASP=m > CONFIG_SND_HRTIMER=m > > This is resulted in disabled options propagating as expected and > CONFIG_SND_HRTIMER worked as well. > > The rest, however didn't. Aha. The kernel configuration audit would have told you that some options were set, and didn't make it into the final .config > > It turned out that basically CONFIG_SND_AM335X_SOC_EVM is misspelled > and should be called CONFIG_SND_AM33XX_SOC_EVM. I think there must be > a way to verify whether this existed or not. > > It then also turned out that CONFIG_SND_AM335X_SOC_EVM depends on > CONFIG_SND_DAVINCI_SOC, and I had to enable that one and ensure it > comes first. And the audit would have told you that you had an invalid option (i.e. the misspelled one didn't appear in any Kconfig in the kernel). > > This is a working set: > > CONFIG_SND_OMAP_SOC=m > CONFIG_SND_OMAP_SOC_MCBSP=m > CONFIG_SND_OMAP_SOC_OMAP_TWL4030=m > CONFIG_SND_SOC_TWL4030=m > CONFIG_SND_DAVINCI_SOC=m > CONFIG_SND_AM33XX_SOC_EVM=m > CONFIG_SND_DAVINCI_SOC_MCASP=m > CONFIG_SND_HRTIMER=m > > >>> The question is really why would this not get detected by >>> kernel_configcheck or any other step? >>> >>> I'm guessing this might be the case of how kconfig works, perhaps... >>> So I wonder whether anyone have looked into how we could actually get >>> the feature dependency graph from kconfig to bitbake or at least some >>> sort of helper tool? Perhaps parsing kconfig manifests in Python would >>> be a starting point... >> >> >> There have been many efforts are changing, writing and processing >> Kconfig constructs in other languages .. they all end up being >> pretty much a re-implementation of Kconfig, and hence a big effort >> that needs to be continuously maintained over time .. also a big >> effort. > > I basically think that we could do something better then blindly > throwing a set of options without verifying it. Ah, but we do verify it. There's a check config task, that used to be more visible, I got complaints and we hid it. I have a 1.7 task to make it more visible again :) > > The reason I mentioned Python was that I though of sharing Kconfig's > dependency graph with bitbake and thereby detecting errors like the > above. > > As a user, this is what I'd love to see: > > Error: The Kconfig option CONFIG_SND_AM335X_SOC_EVM that you have > specified doesn't exist. (Did you mean CONFIG_SND_AM33XX_SOC_EVM?) > > Error: The Kconfig option CONFIG_SND_AM33XX_SOC that you have > specified doesn't exist. (Nothing similar exists) Pretty much already done. > > Warning: The Kconfig option CONFIG_SND_DAVINCI_SOC_MCASP that you have > specified depends on CONFIG_SND_DAVINCI_SOC. I will enable > CONFIG_SND_DAVINCI_SOC as a module for you. This one you can't do without parsing and evaluating all the Kconfigs, which is expensive, and hard to do. We can do something basic by looking at only the direct options within a particular Kconfig, since they are immediately available. But we do detect a whole set of other errors already, and for the most part, they lead pretty quickly to the issue. Bruce > > Hope this makes more sense. > > Cheers, > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Include PaX / GRSecurity 2014-09-08 12:14 ` Bruce Ashfield @ 2014-09-08 12:31 ` Jens Lucius [not found] ` <CAPhDKbH3sj49qfuBnKY-JvD2AGarFpx1PnSOij67Uvr3gABeTg@mail.gmail.com> 1 sibling, 0 replies; 7+ messages in thread From: Jens Lucius @ 2014-09-08 12:31 UTC (permalink / raw) To: yocto I am trying to include the GRSecurity & PaX patches for the kernel in a Yocto build. The patch is applied to the kernel correctly, but when the build begins I get the following error: | Makefile:686: *** Your gcc installation does not support plugins. If the necessary headers for plugin support are missing, they should be installed. On Debian, apt-get install gcc-<ver>-plugin-dev. If you choose to ignore this error and lessen the improvements provided by this patch, re-run make with the DISABLE_PAX_PLUGINS=y argument.. Stop. Any ideas how to solve this? (Compile is on an Intel machine crosscompile for ARM) Thanks, Jens ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <CAPhDKbH3sj49qfuBnKY-JvD2AGarFpx1PnSOij67Uvr3gABeTg@mail.gmail.com>]
* Kernel features [not found] ` <CAPhDKbH3sj49qfuBnKY-JvD2AGarFpx1PnSOij67Uvr3gABeTg@mail.gmail.com> @ 2014-09-08 18:07 ` Ilya Dmitrichenko 2014-09-08 20:02 ` Bruce Ashfield 0 siblings, 1 reply; 7+ messages in thread From: Ilya Dmitrichenko @ 2014-09-08 18:07 UTC (permalink / raw) To: yocto On 8 September 2014 13:14, Bruce Ashfield <bruce.ashfield@windriver.com> wrote: > Ah, but we do verify it. There's a check config task, that used to > be more visible, I got complaints and we hid it. I have a 1.7 task > to make it more visible again :) I have ran kernel_configcheck and it didn't appear to indicate anything. >> Warning: The Kconfig option CONFIG_SND_DAVINCI_SOC_MCASP that you have >> specified depends on CONFIG_SND_DAVINCI_SOC. I will enable >> CONFIG_SND_DAVINCI_SOC as a module for you. > > > This one you can't do without parsing and evaluating all the Kconfigs, > which is expensive, and hard to do. We can do something basic by looking > at only the direct options within a particular Kconfig, since they are > immediately available. I see. Have anyone though of making Kconfig itself to dump out deps tree in JSON or other machine-readable format? > But we do detect a whole set of other errors already, and for the most > part, they lead pretty quickly to the issue. Bruce, that's great to hear! ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Kernel features 2014-09-08 18:07 ` Kernel features Ilya Dmitrichenko @ 2014-09-08 20:02 ` Bruce Ashfield 0 siblings, 0 replies; 7+ messages in thread From: Bruce Ashfield @ 2014-09-08 20:02 UTC (permalink / raw) To: Ilya Dmitrichenko, yocto On 14-09-08 02:07 PM, Ilya Dmitrichenko wrote: > On 8 September 2014 13:14, Bruce Ashfield <bruce.ashfield@windriver.com> wrote: > >> Ah, but we do verify it. There's a check config task, that used to >> be more visible, I got complaints and we hid it. I have a 1.7 task >> to make it more visible again :) > > I have ran kernel_configcheck and it didn't appear to indicate anything. The audit files in the source tree should say something. But maybe they broke (again), when I'm making the results more visible, I'll confirm if it is working properly. Bruce > >>> Warning: The Kconfig option CONFIG_SND_DAVINCI_SOC_MCASP that you have >>> specified depends on CONFIG_SND_DAVINCI_SOC. I will enable >>> CONFIG_SND_DAVINCI_SOC as a module for you. >> >> >> This one you can't do without parsing and evaluating all the Kconfigs, >> which is expensive, and hard to do. We can do something basic by looking >> at only the direct options within a particular Kconfig, since they are >> immediately available. > > I see. Have anyone though of making Kconfig itself to dump out deps > tree in JSON or other machine-readable format? > >> But we do detect a whole set of other errors already, and for the most >> part, they lead pretty quickly to the issue. > > Bruce, that's great to hear! > ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-09-08 20:02 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-07 8:51 Kernel features Ilya Dmitrichenko
2014-09-07 14:17 ` Bruce Ashfield
2014-09-08 5:50 ` Ilya Dmitrichenko
2014-09-08 12:14 ` Bruce Ashfield
2014-09-08 12:31 ` Include PaX / GRSecurity Jens Lucius
[not found] ` <CAPhDKbH3sj49qfuBnKY-JvD2AGarFpx1PnSOij67Uvr3gABeTg@mail.gmail.com>
2014-09-08 18:07 ` Kernel features Ilya Dmitrichenko
2014-09-08 20:02 ` Bruce Ashfield
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.