On Thu, Oct 06, 2022 at 08:52:02AM +0200, David Marchand wrote: > On Wed, Oct 5, 2022 at 6:34 PM Tyler Retzlaff > <roret...@linux.microsoft.com> wrote: > > > > On Wed, Oct 05, 2022 at 09:11:26AM -0700, Tyler Retzlaff wrote: > > > hi David, > > > > > > > > > > > > > > Newly added code can go to eal_common_thread.c rather than introduce a > > > > new common/rte_thread.c file (or is there a rationale for this?). > > > > > > i will make this change in the next revision. if anyone does object i > > > hope they will do so quickly. > > > > looking at this more closely i'm going to back away from making the > > adjustment here. if Thomas and/or Dmitry could comment it would be > > appreciated. > > > > it appears that functions placed in eal_common_xxx files are consumed > > internally by the eal where rte_xxx files are functions that are exposed > > through public api. > > > > since these additions are public api it seems they should remain in > > rte_thread.c > > > > i won't change this in the next revision, but please do correct me if > > i'm still not on track. > > This seems a fair argument. > > > I'll reply on the v5 series: compilation is still broken at patch 4.
can you share what the break is? and which platform/target/toolchain? the only thing I found was that the removal of errno.h broke compilation but that is fixed in v5. the CI run for the series doesn't indicate any compilation failures. assuming i'm looking at the correct results. https://lab.dpdk.org/results/dashboard/patchsets/23789/ it does show a unit test failure but it looks like it is related to a service test that you mailed about within the past few days. thanks
