From: Sergey Matyukevich <geomatsi@gmail.com>
To: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Matt Weber <matthew.weber@collins.com>, buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH 1/2] package/hostapd: update DPP option handling
Date: Mon, 14 Feb 2022 12:39:37 +0300 [thread overview]
Message-ID: <YgojWbviqjNzjSxD@curiosity> (raw)
In-Reply-To: <20220213213809.361f3ea9@windsurf>
Hello Thomas,
> > Makefile hostapd.mk defines different macros for different defconfig
> > options. Options that are not listed in defconfig, can be set using
> > HOSTAPD_CONFIG_SET. Options that are listed in defconfig, can be
> > enabled/disabled using HOSTAPD_CONFIG_ENABLE/HOSTAPD_CONFIG_DISABLE.
> >
> > Starting from hostapd v2.10, option CONFIG_DPP is explicitly listed
> > in defconfig. So it is time to switch to enable/disable macros for
> > this option.
>
> This seems fragile. Why don't we have a single way of enabling an
> option, which doesn't depend on whether the option is listed in the
> hostapd defconfig or not?
What do you think about removal of HOSTAPD_CONFIG_SET and having
something along the following lines for configuration step:
@@ -124,9 +124,11 @@ define HOSTAPD_CONFIGURE_CMDS
cp $(@D)/hostapd/defconfig $(HOSTAPD_CONFIG)
sed -i $(patsubst %,-e 's/^#\(%\)/\1/',$(HOSTAPD_CONFIG_ENABLE)) \
$(patsubst %,-e 's/^\(%\)/#\1/',$(HOSTAPD_CONFIG_DISABLE)) \
- $(patsubst %,-e '1i%=y',$(HOSTAPD_CONFIG_SET)) \
$(patsubst %,-e %,$(HOSTAPD_CONFIG_EDITS)) \
$(HOSTAPD_CONFIG)
+ for opt in $(HOSTAPD_CONFIG_ENABLE) ; do \
+ sed -i -ze "/$${opt}=y/!s/$$/$${opt}=y\n/" $(HOSTAPD_CONFIG) ; \
+ done
endef
This way only HOSTAPD_CONFIG_ENABLED/HOSTAPD_CONFIG_DISABLED macros will
remain. Options that are required, but not listed in defconfig, still
will be appended. There is a chance that next hostapd releases will
introduce some new options for existing functionality, that will require
attention. But there will be no need for shuffling existing options
between CONFIG_SET and CONFIG_ENABLED.
Regards,
Sergey
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2022-02-14 9:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-13 15:52 [Buildroot] [PATCH 0/2] hostapd/wpa_s: fixes after version update Sergey Matyukevich
2022-02-13 15:52 ` [Buildroot] [PATCH 1/2] package/hostapd: update DPP option handling Sergey Matyukevich
2022-02-13 20:38 ` Thomas Petazzoni via buildroot
2022-02-14 9:39 ` Sergey Matyukevich [this message]
2022-02-13 15:52 ` [Buildroot] [PATCH 2/2] package/wpa_supplicant: fix mesh configuration build Sergey Matyukevich
2022-02-13 16:42 ` Arnout Vandecappelle
2022-02-13 16:56 ` Sergey Matyukevich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YgojWbviqjNzjSxD@curiosity \
--to=geomatsi@gmail.com \
--cc=buildroot@buildroot.org \
--cc=matthew.weber@collins.com \
--cc=thomas.petazzoni@bootlin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox