> On Mar 30, 2016, at 3:53 PM, Phil Blundell <[email protected]> wrote: > > On Wed, 2016-03-30 at 17:56 +0000, Khem Raj wrote: >> +Subject: [PATCH] Use UINTPTR_MAX instead of __WORDSIZE >> + >> +Do not include sys/user.h since it conflicts with >> +pt_regs struct from kernel APIs in asm/ptrace.h >> + >> +Signed-off-by: Khem Raj <[email protected]> > > This description (and the subject line of the commit) implies that you > are removing the include unconditionally. But actually, you are only > removing it for non-glibc platforms.
OK.
>
> Also, the change itself seems slightly backwards since the ptrace
> manpage suggests that <sys/user.h> is actually the right header to be
> using for these definitions and possibly it's <asm/ptrace.h> that should
> be eliminated. Maybe that's not feasible here but it would be nice if
> the patch header explained why. And…
The linux ptrace(2) manpage is written with glibc as the only reference.
Unfortunately, its not a POSIX API
so there is no standard per se. The motivation for this patch to look for a
middle ground, between
different libc implementaitons.
musl’s sys/user.h defines elements that conflict with asm/ptrace.h especially
on ppc, may be musl community
should take a closer look at what can be done since many tracing utilities e.g.
strace gdb etc. rely on
this, may be its worth a libc item there.
>
>> -SRC_URI += "file://0001-Typo-in-fuser-makes-M-on-all-the-time.patch \
>> - file://0002-Include-limits.h-for-PATH_MAX.patch \
>> - "
>> +SRC_URI = "${SOURCEFORGE_MIRROR}/psmisc/psmisc-${PV}.tar.gz \
>> + file://0001-Typo-in-fuser-makes-M-on-all-the-time.patch \
>> + file://0002-Include-limits.h-for-PATH_MAX.patch \
>> + file://0001-Use-UINTPTR_MAX-instead-of-__WORDSIZE.patch \
>> + "
>
> ... this change is not mentioned in the commit message. Why have you
> added the tarball to SRC_URI directly (rather than letting the .inc do
> that as it did before)?
>
> p.
>
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
