| Submitter | Matthew McClintock |
|---|---|
| Date | Aug. 21, 2012, 4:20 p.m. |
| Message ID | <1345566017-15508-1-git-send-email-msm@freescale.com> |
| Download | mbox | patch |
| Permalink | /patch/35065/ |
| State | New |
| Headers | show |
Comments
On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock <msm@freescale.com> wrote: > + > +do_configure_prepend (){ > + if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h; then > + export CFLAGS="$CFLAGS -D O_CLOEXEC=0" > + fi > +} IMO It would be safer to create a patch for kmod itself where you define O_CLOEXEC if it was not defined before. The above seems a bit risky
On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj <raj.khem@gmail.com> wrote: > On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock <msm@freescale.com> wrote: >> + >> +do_configure_prepend (){ >> + if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h; then >> + export CFLAGS="$CFLAGS -D O_CLOEXEC=0" >> + fi >> +} > > > IMO It would be safer to create a patch for kmod itself where you > define O_CLOEXEC if it > was not defined before. The above seems a bit risky Why is it risky? I only wanted to do this for affected systems. There is not an easy way to do this with a patch, unless of course I apply the patch manually. -M
On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882 <B29882@freescale.com> wrote: > On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj <raj.khem@gmail.com> wrote: >> On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock <msm@freescale.com> wrote: >>> + >>> +do_configure_prepend (){ >>> + if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h; then >>> + export CFLAGS="$CFLAGS -D O_CLOEXEC=0" >>> + fi >>> +} >> >> >> IMO It would be safer to create a patch for kmod itself where you >> define O_CLOEXEC if it >> was not defined before. The above seems a bit risky > > Why is it risky? I only wanted to do this for affected systems. There > is not an easy way to do this with a patch, unless of course I apply > the patch manually. manually gripping at the host installation and then if O_CLOEXEC might be in comments and furthermore it if it comes from fcntl.h which is not where you are looking for there are few variables like that where its impacting more than affected systems. > > -M
On Tue, Aug 21, 2012 at 1:06 PM, Khem Raj <raj.khem@gmail.com> wrote: > On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882 > <B29882@freescale.com> wrote: >> On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj <raj.khem@gmail.com> wrote: >>> On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock <msm@freescale.com> wrote: >>>> + >>>> +do_configure_prepend (){ >>>> + if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h; then >>>> + export CFLAGS="$CFLAGS -D O_CLOEXEC=0" >>>> + fi >>>> +} >>> >>> >>> IMO It would be safer to create a patch for kmod itself where you >>> define O_CLOEXEC if it >>> was not defined before. The above seems a bit risky >> >> Why is it risky? I only wanted to do this for affected systems. There >> is not an easy way to do this with a patch, unless of course I apply >> the patch manually. > > manually gripping at the host installation and then if O_CLOEXEC might > be in comments How about grep define.*O_CLOEXEC -r ${includedir_native}/bits/fcntl.h > and furthermore it if it comes from fcntl.h which is not where you are > looking for I am grepping this file though? > there are few variables like that where its impacting more than > affected systems. I don't follow... -M
On Tue, Aug 21, 2012 at 11:10 AM, McClintock Matthew-B29882 <B29882@freescale.com> wrote: > On Tue, Aug 21, 2012 at 1:06 PM, Khem Raj <raj.khem@gmail.com> wrote: >> On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882 >> <B29882@freescale.com> wrote: >>> On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj <raj.khem@gmail.com> wrote: >>>> On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock <msm@freescale.com> wrote: >>>>> + >>>>> +do_configure_prepend (){ >>>>> + if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h; then >>>>> + export CFLAGS="$CFLAGS -D O_CLOEXEC=0" >>>>> + fi >>>>> +} >>>> >>>> >>>> IMO It would be safer to create a patch for kmod itself where you >>>> define O_CLOEXEC if it >>>> was not defined before. The above seems a bit risky >>> >>> Why is it risky? I only wanted to do this for affected systems. There >>> is not an easy way to do this with a patch, unless of course I apply >>> the patch manually. >> >> manually gripping at the host installation and then if O_CLOEXEC might >> be in comments > > How about grep define.*O_CLOEXEC -r ${includedir_native}/bits/fcntl.h > >> and furthermore it if it comes from fcntl.h which is not where you are >> looking for > > I am grepping this file though? I would go into the specific file where its asking for O_CLOEXEC and add #ifndef O_CLOEXEC # define O_CLOEXEC 0 #endif and be done with it > >> there are few variables like that where its impacting more than >> affected systems. > > I don't follow... > > -M
On 08/21/2012 11:30 AM, Khem Raj wrote: > On Tue, Aug 21, 2012 at 11:10 AM, McClintock Matthew-B29882 > <B29882@freescale.com> wrote: >> On Tue, Aug 21, 2012 at 1:06 PM, Khem Raj <raj.khem@gmail.com> wrote: >>> On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882 >>> <B29882@freescale.com> wrote: >>>> On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj <raj.khem@gmail.com> wrote: >>>>> On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock <msm@freescale.com> wrote: >>>>>> + >>>>>> +do_configure_prepend (){ >>>>>> + if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h; then >>>>>> + export CFLAGS="$CFLAGS -D O_CLOEXEC=0" >>>>>> + fi >>>>>> +} >>>>> >>>>> >>>>> IMO It would be safer to create a patch for kmod itself where you >>>>> define O_CLOEXEC if it >>>>> was not defined before. The above seems a bit risky >>>> >>>> Why is it risky? I only wanted to do this for affected systems. There >>>> is not an easy way to do this with a patch, unless of course I apply >>>> the patch manually. >>> >>> manually gripping at the host installation and then if O_CLOEXEC might >>> be in comments >> >> How about grep define.*O_CLOEXEC -r ${includedir_native}/bits/fcntl.h >> >>> and furthermore it if it comes from fcntl.h which is not where you are >>> looking for >> >> I am grepping this file though? > > I would go into the specific file where its asking for O_CLOEXEC > > and add > > #ifndef O_CLOEXEC > # define O_CLOEXEC 0 > #endif > > and be done with it > Wasn't this proposed back a month ago: http://lists.linuxtogo.org/pipermail/openembedded-core/2012-July/026343.html And there was discussion about that approach then? I think it was rejected due to lack of testing. Sau! >> >>> there are few variables like that where its impacting more than >>> affected systems. >> >> I don't follow... >> >> -M > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > >
On Tue, Aug 21, 2012 at 1:41 PM, Saul Wold <sgw@linux.intel.com> wrote: > On 08/21/2012 11:30 AM, Khem Raj wrote: >> >> On Tue, Aug 21, 2012 at 11:10 AM, McClintock Matthew-B29882 >> <B29882@freescale.com> wrote: >>> >>> On Tue, Aug 21, 2012 at 1:06 PM, Khem Raj <raj.khem@gmail.com> wrote: >>>> >>>> On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882 >>>> <B29882@freescale.com> wrote: >>>>> >>>>> On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj <raj.khem@gmail.com> wrote: >>>>>> >>>>>> On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock >>>>>> <msm@freescale.com> wrote: >>>>>>> >>>>>>> + >>>>>>> +do_configure_prepend (){ >>>>>>> + if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h; >>>>>>> then >>>>>>> + export CFLAGS="$CFLAGS -D O_CLOEXEC=0" >>>>>>> + fi >>>>>>> +} >>>>>> >>>>>> >>>>>> >>>>>> IMO It would be safer to create a patch for kmod itself where you >>>>>> define O_CLOEXEC if it >>>>>> was not defined before. The above seems a bit risky >>>>> >>>>> >>>>> Why is it risky? I only wanted to do this for affected systems. There >>>>> is not an easy way to do this with a patch, unless of course I apply >>>>> the patch manually. >>>> >>>> >>>> manually gripping at the host installation and then if O_CLOEXEC might >>>> be in comments >>> >>> >>> How about grep define.*O_CLOEXEC -r ${includedir_native}/bits/fcntl.h >>> >>>> and furthermore it if it comes from fcntl.h which is not where you are >>>> looking for >>> >>> >>> I am grepping this file though? >> >> >> I would go into the specific file where its asking for O_CLOEXEC >> >> and add >> >> #ifndef O_CLOEXEC >> # define O_CLOEXEC 0 >> #endif >> >> and be done with it >> > Wasn't this proposed back a month ago: > > http://lists.linuxtogo.org/pipermail/openembedded-core/2012-July/026343.html > > And there was discussion about that approach then? I think it was rejected > due to lack of testing. Then we had a bit more analysis and discussion on the issue and others chimed in they had implemented similar work arounds... it's all in that thread. -M > > >>> >>>> there are few variables like that where its impacting more than >>>> affected systems. >>> >>> >>> I don't follow... >>> >>> -M >> >> >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core >> >> > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
On Tue, Aug 21, 2012 at 1:30 PM, Khem Raj <raj.khem@gmail.com> wrote: > On Tue, Aug 21, 2012 at 11:10 AM, McClintock Matthew-B29882 > <B29882@freescale.com> wrote: >> On Tue, Aug 21, 2012 at 1:06 PM, Khem Raj <raj.khem@gmail.com> wrote: >>> On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882 >>> <B29882@freescale.com> wrote: >>>> On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj <raj.khem@gmail.com> wrote: >>>>> On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock <msm@freescale.com> wrote: >>>>>> + >>>>>> +do_configure_prepend (){ >>>>>> + if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h; then >>>>>> + export CFLAGS="$CFLAGS -D O_CLOEXEC=0" >>>>>> + fi >>>>>> +} >>>>> >>>>> >>>>> IMO It would be safer to create a patch for kmod itself where you >>>>> define O_CLOEXEC if it >>>>> was not defined before. The above seems a bit risky >>>> >>>> Why is it risky? I only wanted to do this for affected systems. There >>>> is not an easy way to do this with a patch, unless of course I apply >>>> the patch manually. >>> >>> manually gripping at the host installation and then if O_CLOEXEC might >>> be in comments >> >> How about grep define.*O_CLOEXEC -r ${includedir_native}/bits/fcntl.h >> >>> and furthermore it if it comes from fcntl.h which is not where you are >>> looking for >> >> I am grepping this file though? > > I would go into the specific file where its asking for O_CLOEXEC > > and add > > #ifndef O_CLOEXEC > # define O_CLOEXEC 0 > #endif > > and be done with it Well this is seemingly the same way of doing it, just looks like you always want it applied? I don't think it should always be applied. If this was it takes to get the build fix in, then I will do it... please confirm what will be accepted. -M > >> >>> there are few variables like that where its impacting more than >>> affected systems. >> >> I don't follow... >> >> -M > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
On Tue, Aug 21, 2012 at 11:41 AM, Saul Wold <sgw@linux.intel.com> wrote: > On 08/21/2012 11:30 AM, Khem Raj wrote: >> >> On Tue, Aug 21, 2012 at 11:10 AM, McClintock Matthew-B29882 >> <B29882@freescale.com> wrote: >>> >>> On Tue, Aug 21, 2012 at 1:06 PM, Khem Raj <raj.khem@gmail.com> wrote: >>>> >>>> On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882 >>>> <B29882@freescale.com> wrote: >>>>> >>>>> On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj <raj.khem@gmail.com> wrote: >>>>>> >>>>>> On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock >>>>>> <msm@freescale.com> wrote: >>>>>>> >>>>>>> + >>>>>>> +do_configure_prepend (){ >>>>>>> + if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h; >>>>>>> then >>>>>>> + export CFLAGS="$CFLAGS -D O_CLOEXEC=0" >>>>>>> + fi >>>>>>> +} >>>>>> >>>>>> >>>>>> >>>>>> IMO It would be safer to create a patch for kmod itself where you >>>>>> define O_CLOEXEC if it >>>>>> was not defined before. The above seems a bit risky >>>>> >>>>> >>>>> Why is it risky? I only wanted to do this for affected systems. There >>>>> is not an easy way to do this with a patch, unless of course I apply >>>>> the patch manually. >>>> >>>> >>>> manually gripping at the host installation and then if O_CLOEXEC might >>>> be in comments >>> >>> >>> How about grep define.*O_CLOEXEC -r ${includedir_native}/bits/fcntl.h >>> >>>> and furthermore it if it comes from fcntl.h which is not where you are >>>> looking for >>> >>> >>> I am grepping this file though? >> >> >> I would go into the specific file where its asking for O_CLOEXEC >> >> and add >> >> #ifndef O_CLOEXEC >> # define O_CLOEXEC 0 >> #endif >> >> and be done with it >> > Wasn't this proposed back a month ago: > > http://lists.linuxtogo.org/pipermail/openembedded-core/2012-July/026343.html > > And there was discussion about that approach then? I think it was rejected > due to lack of testing. I think if it worked fine on a system like cents 5.8 then that would cover the case as well try it on newer systems where O_CLOEXEC is available that should do it. > > Sau! > >>> >>>> there are few variables like that where its impacting more than >>>> affected systems. >>> >>> >>> I don't follow... >>> >>> -M >> >> >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core >> >> >
On Tue, Aug 21, 2012 at 11:48 AM, Khem Raj <raj.khem@gmail.com> wrote: > On Tue, Aug 21, 2012 at 11:41 AM, Saul Wold <sgw@linux.intel.com> wrote: >> On 08/21/2012 11:30 AM, Khem Raj wrote: >>> >>> On Tue, Aug 21, 2012 at 11:10 AM, McClintock Matthew-B29882 >>> <B29882@freescale.com> wrote: >>>> >>>> On Tue, Aug 21, 2012 at 1:06 PM, Khem Raj <raj.khem@gmail.com> wrote: >>>>> >>>>> On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882 >>>>> <B29882@freescale.com> wrote: >>>>>> >>>>>> On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj <raj.khem@gmail.com> wrote: >>>>>>> >>>>>>> On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock >>>>>>> <msm@freescale.com> wrote: >>>>>>>> >>>>>>>> + >>>>>>>> +do_configure_prepend (){ >>>>>>>> + if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h; >>>>>>>> then >>>>>>>> + export CFLAGS="$CFLAGS -D O_CLOEXEC=0" >>>>>>>> + fi >>>>>>>> +} >>>>>>> >>>>>>> >>>>>>> >>>>>>> IMO It would be safer to create a patch for kmod itself where you >>>>>>> define O_CLOEXEC if it >>>>>>> was not defined before. The above seems a bit risky >>>>>> >>>>>> >>>>>> Why is it risky? I only wanted to do this for affected systems. There >>>>>> is not an easy way to do this with a patch, unless of course I apply >>>>>> the patch manually. >>>>> >>>>> >>>>> manually gripping at the host installation and then if O_CLOEXEC might >>>>> be in comments >>>> >>>> >>>> How about grep define.*O_CLOEXEC -r ${includedir_native}/bits/fcntl.h >>>> >>>>> and furthermore it if it comes from fcntl.h which is not where you are >>>>> looking for >>>> >>>> >>>> I am grepping this file though? >>> >>> >>> I would go into the specific file where its asking for O_CLOEXEC >>> >>> and add >>> >>> #ifndef O_CLOEXEC >>> # define O_CLOEXEC 0 >>> #endif >>> >>> and be done with it This does seem like a nicer approach.
On Tue, Aug 21, 2012 at 2:02 PM, Chris Larson <clarson@kergoth.com> wrote: > On Tue, Aug 21, 2012 at 11:48 AM, Khem Raj <raj.khem@gmail.com> wrote: >> On Tue, Aug 21, 2012 at 11:41 AM, Saul Wold <sgw@linux.intel.com> wrote: >>> On 08/21/2012 11:30 AM, Khem Raj wrote: >>>> >>>> On Tue, Aug 21, 2012 at 11:10 AM, McClintock Matthew-B29882 >>>> <B29882@freescale.com> wrote: >>>>> >>>>> On Tue, Aug 21, 2012 at 1:06 PM, Khem Raj <raj.khem@gmail.com> wrote: >>>>>> >>>>>> On Tue, Aug 21, 2012 at 10:59 AM, McClintock Matthew-B29882 >>>>>> <B29882@freescale.com> wrote: >>>>>>> >>>>>>> On Tue, Aug 21, 2012 at 12:54 PM, Khem Raj <raj.khem@gmail.com> wrote: >>>>>>>> >>>>>>>> On Tue, Aug 21, 2012 at 9:20 AM, Matthew McClintock >>>>>>>> <msm@freescale.com> wrote: >>>>>>>>> >>>>>>>>> + >>>>>>>>> +do_configure_prepend (){ >>>>>>>>> + if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h; >>>>>>>>> then >>>>>>>>> + export CFLAGS="$CFLAGS -D O_CLOEXEC=0" >>>>>>>>> + fi >>>>>>>>> +} >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> IMO It would be safer to create a patch for kmod itself where you >>>>>>>> define O_CLOEXEC if it >>>>>>>> was not defined before. The above seems a bit risky >>>>>>> >>>>>>> >>>>>>> Why is it risky? I only wanted to do this for affected systems. There >>>>>>> is not an easy way to do this with a patch, unless of course I apply >>>>>>> the patch manually. >>>>>> >>>>>> >>>>>> manually gripping at the host installation and then if O_CLOEXEC might >>>>>> be in comments >>>>> >>>>> >>>>> How about grep define.*O_CLOEXEC -r ${includedir_native}/bits/fcntl.h >>>>> >>>>>> and furthermore it if it comes from fcntl.h which is not where you are >>>>>> looking for >>>>> >>>>> >>>>> I am grepping this file though? >>>> >>>> >>>> I would go into the specific file where its asking for O_CLOEXEC >>>> >>>> and add >>>> >>>> #ifndef O_CLOEXEC >>>> # define O_CLOEXEC 0 >>>> #endif >>>> >>>> and be done with it > > This does seem like a nicer approach. OK - 2v1 ;) I'll respin as a patch. -M
On Tue, Aug 21, 2012 at 11:47 AM, McClintock Matthew-B29882 <B29882@freescale.com> wrote: >> #ifndef O_CLOEXEC >> # define O_CLOEXEC 0 >> #endif >> >> and be done with it > > Well this is seemingly the same way of doing it, just looks like you > always want it applied? I don't think it should always be applied. > > If this was it takes to get the build fix in, then I will do it... > please confirm what will be accepted. No, on newer systems O_CLOEXEC will be defined, so that #ifndef block will never be entered, and there'll be no change.
On Tue, Aug 21, 2012 at 2:13 PM, Chris Larson <clarson@kergoth.com> wrote: > On Tue, Aug 21, 2012 at 11:47 AM, McClintock Matthew-B29882 > <B29882@freescale.com> wrote: >>> #ifndef O_CLOEXEC >>> # define O_CLOEXEC 0 >>> #endif >>> >>> and be done with it >> >> Well this is seemingly the same way of doing it, just looks like you >> always want it applied? I don't think it should always be applied. >> >> If this was it takes to get the build fix in, then I will do it... >> please confirm what will be accepted. > > No, on newer systems O_CLOEXEC will be defined, so that #ifndef block > will never be entered, and there'll be no change. Right, I was not thinking... -M
Patch
diff --git a/meta/recipes-kernel/kmod/kmod-native_git.bb b/meta/recipes-kernel/kmod/kmod-native_git.bb index 96de8b8..4558c7b 100644 --- a/meta/recipes-kernel/kmod/kmod-native_git.bb +++ b/meta/recipes-kernel/kmod/kmod-native_git.bb @@ -4,7 +4,7 @@ require kmod.inc inherit native -PR = "${INC_PR}.0" +PR = "${INC_PR}.1" do_install_append (){ for tool in depmod insmod lsmod modinfo modprobe rmmod @@ -12,3 +12,9 @@ do_install_append (){ ln -s kmod ${D}${bindir}/$tool done } + +do_configure_prepend (){ + if ! grep O_CLOEXEC -r ${includedir_native}/bits/fcntl.h; then + export CFLAGS="$CFLAGS -D O_CLOEXEC=0" + fi +}
kmod will fail to build with the following error because O_CLOEXEC is not defined: | libkmod/libkmod-module.c: In function 'kmod_module_get_initstate': | libkmod/libkmod-module.c:1640: error: 'O_CLOEXEC' undeclared (first use in this function) | libkmod/libkmod-module.c:1640: error: (Each undeclared identifier is reported only once | libkmod/libkmod-module.c:1640: error: for each function it appears in.) | libkmod/libkmod-module.c: In function 'kmod_module_get_refcnt': | libkmod/libkmod-module.c:1754: error: 'O_CLOEXEC' undeclared (first use in this function) | libkmod/libkmod-module.c: In function 'kmod_module_get_sections': | libkmod/libkmod-module.c:1913: error: 'O_CLOEXEC' undeclared (first use in this function) | libkmod/libkmod-file.c: In function 'kmod_file_open': | libkmod/libkmod-file.c:282: error: 'O_CLOEXEC' undeclared (first use in this function) | libkmod/libkmod-file.c:282: error: (Each undeclared identifier is reported only once | libkmod/libkmod-file.c:282: error: for each function it appears in.) Since we are only using kmod-native for depmod, and it's a non-threaded user of this libary being built this should be safe to override O_CLOEXEC. Keep in mind this is ONLY effecting the native builds and not what is being shipped in the root file system. Signed-off-by: Matthew McClintock <msm@freescale.com> --- meta/recipes-kernel/kmod/kmod-native_git.bb | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)