[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