On Mon, Jul 21, 2025 at 10:05:23AM +0100, Bruce Richardson wrote:
> On Mon, Jul 21, 2025 at 10:41:33AM +0200, David Marchand wrote:
> > On Fri, Jul 18, 2025 at 4:34 PM Bruce Richardson
> > <bruce.richard...@intel.com> wrote:
> > > +struct eal_init_args {
> > > + /* define a struct member for each EAL option, member name is the
> > > same as option name.
> > > + * Parameters that take an argument e.g. -l, are char *,
> > > + * parameters that take no options e.g. --no-huge, are bool.
> > > + * parameters that can be given multiple times e.g. -a, are
> > > arg_lists,
> > > + * parameters that are optional e.g. --huge-unlink,
> > > + * are char * but are set to (void *)1 if the parameter is not
> > > given.
> > > + * NOTE: List is to be kept alphabetically by option name
> > > + */
> >
> > We will have to be careful to keep this struct below, in sync with the
> > options list.
> > Could we construct (at build time) this structure via the options list?
> >
> > The rules above would be enforced at the same time.
> >
> > (macros + #ifdef for Linux/FreeBSD may be an issue for MSVC though...)
> >
>
> I wonder how much an issue keeping them in sync would actually be? When
> adding a new option to the options list, it takes a reference to the struct
> field, meaning that we can't forget to add an entry here when adding the
> option. If we add here but forget to add to the options list, then obvious
> the option just doesn't get parsed so testing quickly would show up the
> issue.
>
> I suppose the main concern would be around renaming or deleting options -
> though in the latter case having an extra stray element in the struct isn't
> a big deal.
>
> I might have a shot at auto-generating the struct, but I'm not convinced
> the complexity will be worth the benefit.
>
Auto-generating the struct seems to work fairly ok. Will include in next
revision.
/Bruce
