> -----Original Message----- > From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de] > Sent: Monday, March 03, 2014 8:10 AM > To: Jennifer Averett > Cc: rtems-devel@rtems.org > Subject: Re: Posix patchs to support affinity attribute in newlib > > On 2014-02-28 16:30, Jennifer Averett wrote: > > > >> >-----Original Message----- > >> >From:rtems-devel-boun...@rtems.org [mailto:rtems-devel- > >> >boun...@rtems.org] On Behalf Of Sebastian Huber > >> >Sent: Friday, February 28, 2014 1:12 AM To:rtems-devel@rtems.org > >> >Subject: Re: Posix patchs to support affinity attribute in newlib > >> > > >> >On 2014-02-27 14:24, Jennifer Averett wrote: > >>> > > /** > >>> > >+ * @brief Copy POSIX Thread attribute structure > >>> > >+ * > >>> > >+ * This routine copies the attr2 thread attribute structure > >>> > >+ * to the attr1 Thread Attribute structure. > >>> > >+ * > >>> > >+ * @param[out] attr1 is a pointer to the thread attribute > >>> > >+ * structure to copy into. > >>> > >+ * > >>> > >+ * @param[out] attr2 is a pointer to the thread attribute > >> > > >> >Should be @param[in]. > >> > > >> >Why not name this src_attr and dst_attr or something similar? > > Will change. > > > > > > If you look at something like this > > /** > * @brief Copy POSIX Thread attribute structure > * > * This routine copies the attr2 thread attribute structure > * to the attr1 Thread Attribute structure. > * > * @param[out] attr1 is a pointer to the thread attribute > * structure to copy into. > * > * @param[in] attr2 is a pointer to the thread attribute > * structure to copy from. > */ > RTEMS_INLINE_ROUTINE void _POSIX_Threads_Copy_attributes( > pthread_attr_t *attr1, > const pthread_attr_t *attr2 > ) > { > *attr1 = *attr2; > #if HAVE_SYS_CPUSET_H > attr1->affinityset = &attr1->affinitysetpreallocated; #endif } > > will you read the comment at all? > > Apart from that the @brief doesn't follow the Doxygen recommendations: > > http://www.rtems.org/wiki/index.php/Doxygen_Recommendations#Declari > ng_functions > > Is the implementation correct for CPU sets which are not pre-allocated? >
Until we have a system that supports over 32 CPU's the implementation can not be tested for this. I minimized the locations that will have to be touched when we support this but I didn't think it was correct to add code that can not be tested. > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
