All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [arc-buildroot] Re: [PATCH] configs/snps_arc*_defconfig: update linux version
Date: Fri, 20 Apr 2018 08:56:44 +0200	[thread overview]
Message-ID: <20180420085644.0adf07e3@windsurf.numericable.fr> (raw)
In-Reply-To: <1524151010.7288.3.camel@synopsys.com>

Hello Evgeniy,

On Thu, 19 Apr 2018 15:16:51 +0000, Evgeniy Didin wrote:
> Hello,
> 
> > Hello,
> > 
> > On Thu, 19 Apr 2018 16:55:24 +0300, Evgeniy Didin wrote:  
> > > With this commit we update Linux kernel version to 4.16.3
> > > and Linux headers version to 4.16.
> > > For some configs we switch headers version to be independent from
> > > Linux kernel version.  
> > 
> > Why ? The change doesn't make you independent at all from the Linux
> > kernel version, and causes two kernel tarballs to be downloaded instead
> > of one, which isn't nice.
> > 
> > Could you justify this change ?  
> 
> With option BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_1*=y
> BR2_KERNEL_HEADERS_AS_KERNEL parameter is set.

Yes, and this is what we want.

> Defconfig is meant as a starting point for work with the board.
> In these case if user wants to change version of Linux kernel,
> such error appears:
> ---------------------------->8---------------------------------  
> Incorrect selection of kernel headers: expected 4.16.x, got 4.15.x,
> ----------------------------8<---------------------------------
> Also in case of choosing new kernel rc's, error 404 occurs.
> For inexperienced users, these errors may not be obvious.

I do understand your concern. However, it is actually even worse if
your defconfig selects 4.16 kernel headers: if the user changes
the kernel version itself from 4.16 to 4.10, the user will
run a 4.10 kernel, with a toolchain compiled against 4.16 kernel
headers, which isn't good.

Also, specifying a fixed kernel headers version like you're doing means
that the kernel source code gets downloaded twice.

In addition all our defconfigs use this principle, and we are not going
to change this principle for just a few defconfigs. Either we change
this for all defconfigs, or we keep it as is for all defconfigs.
Therefore, I would recommend you to bump the Linux kernel version in
the snps_arc_* defconfigs without changing this, and if you really
think the current situation is not convenient, open up the discussion
inn a broader way.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

      reply	other threads:[~2018-04-20  6:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-19 13:55 [Buildroot] [PATCH] configs/snps_arc*_defconfig: update linux version Evgeniy Didin
2018-04-19 14:15 ` Thomas Petazzoni
2018-04-19 15:16   ` [Buildroot] [arc-buildroot] " Evgeniy Didin
2018-04-20  6:56     ` Thomas Petazzoni [this message]

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=20180420085644.0adf07e3@windsurf.numericable.fr \
    --to=thomas.petazzoni@bootlin.com \
    --cc=buildroot@busybox.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.