MIPS NPTL patches [1/3]

[Mike Frysinger]

On Thursday 09 April 2009 06:10:26 Dan E wrote:
> On Thu, 09 Apr 2009 04:33 -0400, "Mike Frysinger" wrote:
> > On Thursday 09 April 2009 04:01:23 Dan E wrote:
> > > 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.
>
> Umm... yes, we are.  Why would I submit a patch against the trunk when
> there is zero chance that update is going to be pulled across into the
> nptl branch? <snip>

you are mistaken.  if you look at actual commits, you'll see that changes are 
actively taken from trunk into the nptl branch so that the merge from branch 
into trunk is smoother.

> > > 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*.
>
> They're hardly irrelevant when the code fails to compile without
> supporting changes.

no information on supported changes == rejection

> Granted, some of them were unnecessary due to an
> oversight on my part (please see my replies to Khem and Carmello)

and if you include *real information* like i asked, then this would have been 
established much sooner.  trying to cop out with general statements "MIPS has 
been broken" makes it look like you really have no idea why the change is 
needed, and indeed gets us to back to the reality of the changes werent 
actually necessary.

> You seem completely unaware of the current dichotomy between the trunk
> and the nptl branch.

you might want to avoid assumptions, especially when they're invalid

> I don't think they're as close as you seem to
> think they are at the moment.

i know the branch is behind, but making changes to common code with no real 
information isnt helping anything and generally is the opposite: making the 
situation worse.

a commit log of "the change is necessary" is garbage.  now, if perhaps you 
split up the changes as "here are changes that are already in trunk but are 
not in the branch and fix building for MIPS", then no one would have looked 
twice.  but you didnt, and here we are pissing everywhere and not getting any 
actual work done.
-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/f91c7cc4/attachment.pgp>