[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160302231808.GO9349@brightrain.aerifal.cx>
Date: Wed, 2 Mar 2016 18:18:08 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: iproute2 & other software
On Wed, Mar 02, 2016 at 12:44:51PM -0800, Khem Raj wrote:
>
> > On Mar 2, 2016, at 12:39 PM, Loganaden Velvindron <loganaden@...il.com> wrote:
> >
> >
> >
> > On Wed, Mar 2, 2016 at 8:37 PM, Khem Raj <raj.khem@...il.com <mailto:raj.khem@...il.com>> wrote:
> >
> > > On Mar 2, 2016, at 11:19 AM, Loganaden Velvindron <loganaden@...il.com <mailto:loganaden@...il.com>> wrote:
> > >
> > > Hi All,
> > >
> > > Stephen (iproute2) sent me a mail telling me that he rejected my patch to iproute2 for musl support:
> > >
> > > 1st reply:
> > > "
> > > I was waiting for others who had more to say on this.
> > > Ok with providing small fixes, but can't really guarantee iproute to
> > > work with other libraries.
> > > "
> > >
> > > & 2nd is :
> > > "
> > > Sorry, I have to reject this.
> > > All include files in include/linux come from headers automatically generated from upstream
> > > Linux source. This is the only way to ensure long term ABI/API consistency
> > > with kernel.
> > >
> > > Either fix musl or submit patches to upstream kernel and get them merged.
> > > “
> >
> > Where is your patch.
> >
> >
> > Rejected patch here:
> >
> > https://patchwork.ozlabs.org/patch/586121/ <https://patchwork.ozlabs.org/patch/586121/>
> >
>
> The change needs a bit more description of the problem its trying to fix.
> Concern is if it will still work with glibc or uclibc on linux
> one way you could keep functionality same for existing libcs
> is to ifdef these files with #ifdef __GLIBC__
Indeed, I don't think the patch makes sense as submitted. MAXPATHLEN
is a deprecated, nonstandard form of PATH_MAX and should not be used
at all; adding #include <sys/param.h>, a messy legacy header with a
hodgepodge of junk in it, is making the codebase worse rather than
better.
Removing #include <linux/in.h> and #include <linux/in6.h> is probably
correct, but you should check and explain that all the types used from
these headers are already defined by standard headers (netinet/in.h?)
and that including the redundant Linux headers at best creates a risk
of conflict and if nothing else is useless.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
