On Fri, Jun 28, 2019 at 2:40 PM Bruce Richardson <[email protected]> wrote:
> On Thu, Jun 27, 2019 at 03:22:14PM +0200, David Marchand wrote: > > On Wed, May 29, 2019 at 5:42 PM Bruce Richardson > > <[1][email protected]> wrote: > > > > Rather than using enum values for CPU flags, which means the symbols > > don't > > exist on other architectures, provide a flag lookup by name, > > allowing us to > > unconditionally check for a CPU flag. > > > > Did you consider passing a string for the CPU architecture rather than > > an enum? > > It would have to be compared to RTE_ARCH in > > rte_cpu_get_flagname_enabled. > > Or to accomodate with x86_64/i686, this could be a cpu arch family. > > This avoids adding a new C type that seems quite limited wrt its uses. > > -- > > David Marchand > > > > I'm not sure I really see the value in having string names for the > architecture values, I think it would be a lot more clunky to manage rather > than having an enum value. The key difference vs the flags is that the > flags are only valid per-architecture while the architecture defines can be > globally valid, and secondly there is a finite, and small, number of > architectures compared to the number of flags supported. > > If you feel strongly about it I can investigate it, but I'm not sure I see > the value in doing so right now if the only benefit is avoiding the enum. > I suppose we won't have too much trouble handling ABI breakage (thinking about when we will remove x86 support). Ok, let's go with this. -- David Marchand
