MIPS NPTL patches [1/3]

Dan E trg_info at mailhaven.com
Thu Apr 9 08:01:23 UTC 2009


On Thu, 09 Apr 2009 02:54 -0400, "Mike Frysinger" <vapier at gentoo.org>
wrote:
> On Wednesday 08 April 2009 23:44:07 Dan E wrote:
> > ---------- patch start ----------
> 
> posting patches inline meant for direct inclusion really only works when:
>  - it's only 1 patch
>  - patch is at the end of the e-mail
> 
> multiple patches should either be separate e-mails or attached.  there
> should 
> also be a short description of each one individually.

Thanks for the feedback, Mike.  What constitutes "multiple patches"?  I
did submit 4 different emails, and aside from the fact that the first 2
should have been combined into 1, i.e. treated as a whole, the others
were split off for specific reasons.

I'm not very experienced at posting patches, as you can tell, but I
remember reading quite recently that posting patches inline was the
preferred way of doing it.  In fact, I'm quite certain that attachments
were frowned upon in some quarters.  Regardless, whatever the maintainer
wants, the maintainer gets.  I hadn't noticed a preference for one over
another.

> > --- uClibc-nptl/include/unistd.h	(revision 26031)
> > +++ uClibc-nptl/include/unistd.h	(working copy)
> > -extern void __exit_thread (int val) __attribute__ ((noreturn));
> > +extern void __exit_thread (int val) __attribute__ ((__noreturn__));
> 
> for changes clearly not related to NPTL, these should go into trunk and
> split out of any NPTL-specific changes.

I have no interest in the trunk right now.  If the NPTL code was in the
trunk then I would wholeheartedly agree with you 100%.  As it stands
today, however, we're talking apples and oranges.

> > --- uClibc-nptl/libc/signal/sigpause.c	(revision 26031)
> > +++ uClibc-nptl/libc/signal/sigpause.c	(working copy)
> > +#include <string.h>
> 
> for changes not related to your arch let alone NPTL, you should be
> describing exactly why it's needed.  a simple copy & paste of a compile error
> usually suffices.
> -mike

4 years of non-working MIPS NPTL isn't enough?  Sorry, I don't mean to
be snarky.  Are you aware of the current situation as regards trunk vs.
the nptl branch?  Certain aspects of your reply lead me to believe that
maybe you are not.

DanE

-- 
http://www.fastmail.fm - mmm... Fastmail...



More information about the uClibc mailing list