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