Re: [PATCH] linux-kernel-base: linux/version.h path update for 3.7-rc1

[Bruce Ashfield <bruce.ashfield@gmail.com>]

On Wed, Mar 27, 2013 at 5:25 AM, Anders Roxell <anders.roxell@gmail.com> wrote:
>
> On Wed, Mar 20, 2013 at 4:30 PM, Bruce Ashfield <bruce.ashfield@gmail.com>
> wrote:
>>
>> On Wed, Mar 20, 2013 at 10:55 AM, Anders Roxell <anders.roxell@gmail.com>
>> wrote:
>> >
>> >
>> >
>> > On Wed, Mar 20, 2013 at 2:42 PM, Bruce Ashfield
>> > <bruce.ashfield@gmail.com>
>> > wrote:
>> >>
>> >> On Wed, Mar 20, 2013 at 9:22 AM,  <anders.roxell@gmail.com> wrote:
>> >> > From: Anders Roxell <anders.roxell@enea.com>
>> >> >
>> >> > In mainline kernel 3.7-rc1 (hash:abbf1590de22a6d22)
>> >> > The path include/linux/version.h was updated to
>> >> > include/generated/uapi/linux/version.h
>> >>
>> >> It's true that uapi now holds the generated version.h, but what build
>> >> error were you seeing without this change in place ?
>> >
>> >
>> > We were trying to build linx
>> > (http://linx.sourceforge.net/linxdoc/doc/index.html)
>> > Please let me know if it is better to rewrite linx or include this
>> > patch?
>>
>> My concern is that as a list of alternatives builds up over time, that
>> don't
>> necessarily use the same format of the linux version, you'll end up with
>> applications that are making the wrong decisions if a fallback is used.
>> Having
>> a clear public / exported file, and throwing errors if it doesn't exist
>> would
>> ensure consistent behaviour (granted annoying if you get the error when
>> you
>> think you shouldn't).
>>
>> If you look at the code in get_kernelversion() it shouldn't even work if
>> version.h is used versus utsrelease.h.  I'd be inclined to suggest the
>> removal of the existing version.h fallback, versus adding another.
>>
>> You might not even need to modify the application code to fix this. What
>> are the dependencies of your recipe that would allow for utsrelease.h
>> to not be generated when the build calls get_kernelversion ?
>>
>
> Sorry for the late response!
> I agree with you that its better to use utsrelease.h rather than depending
> on version.h.
>
> We have added a patch for the linx source to solve this.
>
> Thank you very much for the help and support!

I was wondering about how this went a day or so ago .. and now I know.
Glad to hear it worked out!

Cheers,

Bruce

>
> With kind regards,
> Anders
>
>>
>> Cheers,
>>
>> Bruce
>>
>> >
>> > Regards,
>> > Anders
>> >
>> >>
>> >> utsrelease.h is
>> >> still created where it has been for some time, and should be what is
>> >> typically used for any version checks.
>> >>
>> >> Cheers,
>> >>
>> >> Bruce
>> >>
>> >>
>> >>
>> >> >
>> >> > Signed-off-by: Anders Roxell <anders.roxell@enea.com>
>> >> > ---
>> >> >  meta/classes/linux-kernel-base.bbclass |    3 +++
>> >> >  1 files changed, 3 insertions(+), 0 deletions(-)
>> >> >
>> >> > diff --git a/meta/classes/linux-kernel-base.bbclass
>> >> > b/meta/classes/linux-kernel-base.bbclass
>> >> > index 4f2b0a4..b7d0ffa 100644
>> >> > --- a/meta/classes/linux-kernel-base.bbclass
>> >> > +++ b/meta/classes/linux-kernel-base.bbclass
>> >> > @@ -8,6 +8,9 @@ def get_kernelversion(p):
>> >> >          fn = p + '/include/generated/utsrelease.h'
>> >> >      if not os.path.isfile(fn):
>> >> >          fn = p + '/include/linux/version.h'
>> >> > +    if not os.path.isfile(fn):
>> >> > +        # after 3.7-rc1
>> >> > +        fn = p + '/include/generated/uapi/linux/version.h'
>> >> >
>> >> >      import re
>> >> >      try:
>> >> > --
>> >> > 1.7.5.4
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Openembedded-core mailing list
>> >> > Openembedded-core@lists.openembedded.org
>> >> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>> >>
>> >>
>> >>
>> >> --
>> >> "Thou shalt not follow the NULL pointer, for chaos and madness await
>> >> thee at its end"
>> >
>> >
>>
>>
>>
>> --
>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>> thee at its end"
>
>



--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"