Re: [dpdk-dev] [PATCH v1 2/2] mk: add sensible default target with defconfig

[Shreyansh Jain <shreyansh.jain@nxp.com>]

Hi David,

> -----Original Message-----
> From: Hunt, David [mailto:david.hunt@intel.com]
> Sent: Thursday, May 25, 2017 6:34 PM
> To: Shreyansh Jain <shreyansh.jain@nxp.com>
> Cc: dev@dpdk.org; thomas@monjalon.net
> Subject: Re: [PATCH v1 2/2] mk: add sensible default target with defconfig
> 
> Hi Shreyansh,
> 
> Thanks for your comments. More thoughts below.
> 
> On 24/5/2017 7:10 AM, Shreyansh Jain wrote:
> > Hello David,
> >
> > On Tuesday 23 May 2017 03:58 PM, David Hunt wrote:
> >> Users can now use 'make defconfig' to generate a configuration using
> >> the most appropriate defaults for the current machine.
> >>
> >> <arch-machine-execenv-toolchain>
> >>   arch taken from uname -m
> >>   machine defaults to native
> >>   execenv is taken from uname, Linux=linuxapp, otherwise bsdapp
> >>   toolchain is taken from $CC -v to see which compiler to use
> >>
> >> Signed-off-by: David Hunt <david.hunt@intel.com>
> >> ---
> >>  mk/rte.sdkconfig.mk | 15 ++++++++++++---
> >>  mk/rte.sdkroot.mk   |  4 ++--
> >>  2 files changed, 14 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/mk/rte.sdkconfig.mk b/mk/rte.sdkconfig.mk
> >> index 1f2d6bd..4f30d56 100644
> >> --- a/mk/rte.sdkconfig.mk
> >> +++ b/mk/rte.sdkconfig.mk
> >> @@ -60,16 +60,25 @@ showconfigs:
> >>
> >>  .PHONY: notemplate
> >>  notemplate:
> >> -    @printf "No template specified. "
> >> -    @echo "Use T=template among the following list:"
> >> +    @printf "No template specified. Use 'make defconfig' or "
> >> +    @echo "use T=template from the following list:"
> >>      @$(MAKE) -rR showconfigs | sed 's,^,  ,'
> >>
> >> +
> >> +.PHONY: defconfig
> >> +defconfig:
> >> +    @$(MAKE) config T=$(shell uname -m)-native-$(shell uname | \
> >
> > The idea to have 'make defconfig' do the works looks great to me.
> > I am just worried about the above line - it wouldn't allow
> > configurations like
> > arm64-dpaa2-linuxapp-gcc or arm64-armv8a-linuxapp-gcc
> > Basically, having the MACHINE default to 'native' would not be right
> > in all cases.
> >
> > But, I don't have a better idea about how to detect this automatically.
> > Or, we might use RTE_MACHINE someway.
> >
> 
> Might I suggest that we default to armv8a for the defconfig in this
> case? Would that be good enough? If you need something more specific,
> then use the normal make config T=
> Also, if you're using an unknown variant, you can always set your
> RTE_TARGET, as per the other changes in the patch.

Yes. It is futile to find a way to accommodate all types of MACHINEs.
This change is targeted for generalizing the config detection, and
generic it should remain.

> 
> A possible proposal for a v2 patch could be:
> 
> uname -m  Output Target
> --------  ------------------
> aarch64   arm64-armv8a-...
> armv7l    arm-armv7a-...
> ppc64     ppc_64-power8-... (from wikipedia uname page, could ppc user
> confirm this for me?)
> x86_64    x86_64-native-...
> i686      i686-native-...
> 
> Something along the lines of:
> 
> .PHONY: defconfig
> defconfig:
>          @$(MAKE) config T=$(shell \
>                  uname -m | awk '{ \
>                  if ($$0 == "aarch64") { \
>                          print "arm64-armv8a"} \
>                  else if ($$0 == "armv7l") { \
>                          print "arm-armv7a"} \
>                  else if ($$0 == "ppc64") { \
>                          print "ppc_64-power8"} \
>                  else { \
>                          printf "%s-native", $$0} }')-$(shell \
>                  uname | awk '{ \
>                  if ($$0 == "Linux") { \
>                          print "linuxapp"} \
>                  else { \
>                          print "bsdapp"} }')-$(shell \
>                  ${CC} -v 2>&1 | \
>                  grep " version " | cut -d ' ' -f 1)
> 
> That might make a reasonable start in the absence of a reliable method
> of detecting Xgene/ThunderX/DPAA2 variants.
 
Sounds reasonable to me. We can probably improve the above check in
future as and more definitive way of detecting machine are identified.
I can ack the series if you can push the above change.

> 
> Regards,
> Dave.
> 
> 
> 

-
Shreyansh