[OE-core] [PATCH] linux-libc-headers: fix duplicate IFF_LOWER_UP DORMANT ECHO on musl

[Mikko.Rapeli at bmw.de]

On Fri, Jun 23, 2017 at 04:20:41PM -0700, Khem Raj wrote:
> On Fri, Jun 23, 2017 at 7:17 AM,  <Mikko.Rapeli at bmw.de> wrote:
> > Hi,
> >
> > I'm chipping in since I've been messing with these things a bit in upstream
> > Linux kernel.
> >
> > On Fri, Jun 23, 2017 at 06:37:52AM -0700, Khem Raj wrote:
> >> On Fri, Jun 23, 2017 at 3:46 AM, André Draszik <git at andred.net> wrote:
> >> > connman is not doing anything wrong here.
> >> >
> >>
> >> yes I am aware of this
> >>
> >> > The kernel is redefining IFF_LOWER_UP, because it thinks the libc doesn't
> >> > define it yet (and glibc doesn't).
> >> >
> >> > libc-compat.h is the way to solve these kind of issues. There also is https:
> >> > //lkml.org/lkml/2017/3/12/238 which is very similar. I'll pick that instead.
> >> >
> >> see the comment https://lkml.org/lkml/2017/3/16/121
> >> that worries me for this patch
> >
> > I'm aware of those review comments but I have not seen any patches posted which
> > fix the problem in some other way. Thus I would propose to apply these patches
> > as a workaround until upstream fixes the issues.
> >
> > These header files do not change that often either.
> 
> problem is you become incompatible ABI forever that worries me.
> However if bruce is fine to carry this patch as part of linux-yocto
> I might relent. It still will be hassle where folks will have to apply
> this patch to there kernels if they are building musl based systems.

API or ABI? But agreed this is a problem.

> >
> >> I am not questioning the correctness of patch too. But
> >> it would be better to get this patch accepted into kernel
> >> before applying to OE since these are kind of patches which
> >> you can get stuck with for life if upstream is not accepting it.
> >
> > Upstream-Status: Denied
> >
> > would be a correct marker for now I guess.
> 
> I would rather see some progress made to get it resolved :)
> we need to actually remove glibc'ness completely from kernel.
> and this will fix itself.

Yes. With the glibc'ness in the kernel headers I was just following existing
examples and adding some more. Some of those changes got accepted and only
later came the resistance to remove glibc'ness completely. No-one else
has proposed patches. Maybe I should invent some hobby project time again
for this...

-Mikko