Re: [PATCH] cell spu offloading printf and friends

[Jeff Johnston <jjohnstn at redhat dot com>]

jschopp wrote:
> Jeff Johnston wrote:
> > What about errno?  
>
> Since errno is always returned in the same slot it is handled by the 
> helper function, see this line:
>  >> +    errno = ret->slot[3];

Missed that.

> > What about the reentrancy struct which contains errno for the current 
> > thread?
>
> The cell spu is single threaded, so I don't think it's necessary.  Be 
> happy to add a line if I'm wrong, which is not unheard of.

Not at present.

> > Is there any storage allocated by any of the routines?  Who cleans it 
> > up?  
>
> The only storage is allocated on the spu is on the stack and thus goes 
> away on function return.
>
> > Are positional parameters supported by the printf family?  If not, do 
> > you need them for NLS?
>
> I suppose I don't know what positional parameters are.  The only 
> supported locale on the spu is the C locale, publicly documented by 
> definition of the architecture.  In any case the parameters just get 
> shuffled around on the other side and currently are handled by glibc in 
> the end.

So, if I understand correctly, you're punting functionality to another 
processor which has a full glibc on it.  If you have a glibc 
implementation then yes, you have positional parameter support and more.

> > What testing has been performed?
>
> This has all gone through our testing for the SDK 2.0 
> http://www.bsc.es/projects/deepcomputing/linuxoncell/  A number of 
> different groups tested that release in various ways.  I personally ran 
> the limited newlib test suite and the rather decent gcc testsuite on 
> it.  I also wrote a few custom testcases. Sony has been using these 
> patches too, and I'm sure they've done some amount of testing, because 
> they found the same bugs we did and offered similar fixes as we had done.

Ok, that's what I was needing to hear.

> > With all the questions I have, I am very doubtful about this being put 
> > into 1.15.0.
>
> Well, I'll save myself the trouble of sending the follow on until we can 
> work out this one.  It's ultimately your decision what goes in or 
> doesn't.  But something to keep in mind is that everyone who actually 
> uses newlib on the spu will be using this patch if it is in or not.  The 
> current method is simply not viable for real use.

My questions have been answered.

-- Jeff J.