All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Bruce Ashfield" <bruce.ashfield@gmail.com>
To: Mike Looijmans <mike.looijmans@topic.nl>
Cc: "peter@berginkonsult.se" <peter@berginkonsult.se>,
	 "yocto@lists.yoctoproject.org" <yocto@lists.yoctoproject.org>
Subject: Re: [yocto] linux-libc-headers - how to handle for older kernels?
Date: Mon, 2 Dec 2019 08:44:11 -0500	[thread overview]
Message-ID: <CADkTA4O_vBgX-PRssZbCgzMDsyVr6LyoscXEAe5qyHFCJPu+rw@mail.gmail.com> (raw)
In-Reply-To: <dcb9a8b4-88c5-5b1e-00ba-4b89f809e3d3@topic.nl>

On Mon, Dec 2, 2019 at 4:14 AM Mike Looijmans <mike.looijmans@topic.nl> wrote:
>
> On 01-12-19 22:57, Peter Bergin via Lists.Yoctoproject.Org wrote:
> > Hi,
> >
> > I'm currently working in a project using Yocto 2.6 (thud) release. It has
> > default kernel v4.18 and also linux-libc-headers from kernel v4.18. In my
> > project we will use kernel v4.1. I would like advice how to handle the
> > linux-libc-headers package for my project, should I use the v4.18 headers or
> > should I use the v4.1 header files which matches the running kernel?
> >
> >  From https://www.kernel.org/doc/html/latest/kbuild/headers_install.html:
> > "Kernel headers are backwards compatible, but not forwards compatible. This
> > means that a program built against a C library using older kernel headers
> > should run on a newer kernel (although it may not have access to new
> > features), but a program built against newer kernel headers may not work on an
> > older kernel."
> >
> > With the information from the quote above I would directly use v4.1 headers as
> > my linux-libc-headers. But then reading the information in the file
> > meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc makes me think
> > another round. It states:
> >
> > "
> > # You're probably looking here thinking you need to create some new copy
> > # of linux-libc-headers since you have your own custom kernel. To put
> > # this simply, you DO NOT.
> > ...
> > # There can also be a case where your kernel extremely old and you want
> > # an older libc ABI for that old kernel. The headers installed by this
> > # recipe should still be a standard mainline kernel, not your own custom
> > # one.
> > "
> >
> > The first part states that I should not change linux-libc-headers. But when I
> > read the last part I'm not sure about the interpretation and it could be for
> > my case. Just a matter of definition if v4.1 is extremely old compared to v4.18.
> >
> > Then another thing comes in to the equation; the LIBC ABI. When I look into
> > the configuration of the glibc package it uses the configure switch
> > "--enable-kernel=3.2" which means it shall be compatible with all kernel newer
> > than v3.2. Then probably glibc is fine if it is compiled with v4.18 and run on
> > v4.1?
> >
> > If building all applications against v4.18 headers but run on v4.1 kernel. I
> > have a feeling that there potentially can be problems here.
> >
> > Please help me with some information about this and share your opinions? Are
> > there any risks at all to use v4.1 as linux-libc-headers in my Yocto build?
> > The only drawback I see is that it will be a new configuration not well tested
> > by the community. Are there other risks or drawbacks using your own version of
> > linux-libc-headers?
>
>
> It is not broken, so please don't fix it.
>
> OpenPLi has been using kernels way older than 4.1 with the kernel-headers
> generated by OE/yocto and did not experience any problems with that. There's
> about 50+ machines in there that have pre-built binary drivers that only work
> with a particular kernel config and hence the old stuff.
>
> There are some corner-cases with exotic kernels and exotic exports and exotic
> boot executables that use the kernel compiler, but I doubt that you're in there...
>
> If you have a kernel that exports something that's not in the regular headers,
> it's way better to solve that using a syscall than trying to poke in low level
> libc stuff.
>
> So again, if you don't experience problems, please don't try to fix it...

This has been my experience as well.

I've run a really wide set of BSP kernel's against the various "much
newer" yocto/OE libc-headers over the years, and I've never hit an ABI
or otherwise incompatibility.

Like Mike is saying, if you probably have a feeling if your BSP is
doing anything exotic and can explicitly test those problem areas, or
put in place some specific workarounds if there are some changed or
different interfaces.

Cheers,

Bruce

>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#47483): https://lists.yoctoproject.org/g/yocto/message/47483
> Mute This Topic: https://lists.yoctoproject.org/mt/64460477/1050810
> Group Owner: yocto+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  [bruce.ashfield@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

  parent reply	other threads:[~2019-12-02 13:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-01 21:57 linux-libc-headers - how to handle for older kernels? Peter Bergin
2019-12-02  9:01 ` [yocto] " Mikko Rapeli
2019-12-02  9:13 ` Mike Looijmans
2019-12-02  9:19   ` Mikko Rapeli
2019-12-02  9:28     ` Mike Looijmans
2019-12-02  9:33       ` Mikko Rapeli
2019-12-02 14:01         ` Adrian Bunk
2019-12-02 14:09           ` Mikko Rapeli
2019-12-02 13:44   ` Bruce Ashfield [this message]
2019-12-03  7:59     ` Peter Bergin
2019-12-03 15:28       ` Bruce Ashfield
2019-12-04  7:46         ` Peter Bergin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CADkTA4O_vBgX-PRssZbCgzMDsyVr6LyoscXEAe5qyHFCJPu+rw@mail.gmail.com \
    --to=bruce.ashfield@gmail.com \
    --cc=mike.looijmans@topic.nl \
    --cc=peter@berginkonsult.se \
    --cc=yocto@lists.yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.