[Cbe-oss-dev] spufs: issues in spu* man pages

Noguchi, Masato Masato.Noguchi at jp.sony.com
Wed Jul 25 21:07:01 EST 2007


Arnd,
Thanks for your reply. 

> Please keep the Cc-list. Not all the people working on the man pages
> are subscribed to cbe-oss-dev.

Sorry to put you to the trouble.
I'll take care of it from next time.



> -----Original Message-----
> Subject: Re: [Cbe-oss-dev] spufs: issues in spu* man pages
> 
> On Wednesday 25 July 2007, Noguchi, Masato wrote:
> > Hi,
> >
> > I noticed some trivial issues in spu* man pages Arnd posted here
> > before. So, I report them.
> 
> Please keep the Cc-list. Not all the people working on the man pages
> are subscribed to cbe-oss-dev.
> 
> > * Section number of spufs
> >
> >   The filename is "spufs.7", but "2" is specified in it.
> 
> needs to be 7
> 
> > * Default mode of spufs
> >
> >   man pages says that the default mode of the top-level directory in
> >   spufs is 0755, but actually kernel sets 0775. Which is correct?
> 
> the kernel is correct by definition, man page should change.
> 
> > * SPE_EVENT_INVALID_DMA
> >
> >   spu_run syscall may return SPE_EVENT_INVALID_DMA as event, but
> >   it is not documented in man pages. I guess it's simply forgotten
to
> >   add.
> 
> yes
> 
> > * SPE_EVENT_SPE_DATA_SEGMENT and SPE_EVENT_DATA_STORAGE
> >
> >   On current implementation, all memory access violations of spe dma
> >   are mapped to SPE_EVENT_DATA_STORAGE, and SPE_EVENT_DATA_SEGMENT
is
> >   never raised.
> >   I feel any other events are well-defined because they are almost
> >   directly mapped from cell hardware interrupts, but above two are
not
> >   so. Thus, more descriptions are needed, I guess.
> 
> yes, agreed. thanks for your feedback!
> _______________________________________________
> cbe-oss-dev mailing list
> cbe-oss-dev at ozlabs.org
> https://ozlabs.org/mailman/listinfo/cbe-oss-dev





More information about the cbe-oss-dev mailing list