MIPS NPTL patches [1/3]

Mike Frysinger vapier at gentoo.org
Thu Apr 9 08:33:01 UTC 2009


On Thursday 09 April 2009 04:01:23 Dan E wrote:
> On Thu, 09 Apr 2009 02:54 -0400, "Mike Frysinger" 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.

patches should be logically related.  the patch i replied to, from what i 
could see, were unrelated changes.

> 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.

going by the "---------- patch start ----------", i thought you had multiple 
markers, but i guess not.

if you want some good guidelines for how to work with patches, then read the 
SubmittingPatches document that's in the kernel

> > > --- 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.

no we arent.  if you were only touching NPTL files (like ldso/ or libpthread/) 
that would be one thing.  but you arent.

> > > --- 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.
>
> 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.

why dont you read the lines i quoted.  i made no statement at all about the 
mips or ldso or nptl files.  i did however take issue with seemingly random 
unrelated changes in include/ and libc/.  "4 years of non-working MIPS NPTL" 
is hardly relevant when you go around changing attributes and adding includes 
in *completely common code*.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/uclibc/attachments/20090409/df199c84/attachment-0001.pgp>


More information about the uClibc mailing list