Message ID | cover.1532086504.git.horms+renesas@verge.net.au |
---|---|
State | New |
Headers | show |
Series | [GIT,PULL] Renesas ARM Based SoC Defconfig Updates for v4.19 | expand |
On Fri, Jul 20, 2018 at 02:03:54PM +0200, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM based SoC defconfig updates for v4.19. > > > The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40: > > Linux 4.18-rc1 (2018-06-17 08:04:49 +0900) > > are available in the git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-arm-defconfig-for-v4.19 > > for you to fetch changes up to e82c98d0448c60706a8024d460eadb9d7402dcba: > > ARM: multi_v7_defconfig: Enable support for RZN1D-DB (2018-07-13 10:15:20 +0200) > > ---------------------------------------------------------------- > Renesas ARM Based SoC Defconfig Updates for v4.19 > > multi_v7_defconfig and shmobile_defconfig Enhancement: > > * Enable support for recently upstreamed RZN1D-DB board > in multi_v7_defconfig and shmobile_defconfig. This is > to give better test coverage. > > shmobile_defconfig Clean-Up: > > * Drop NET_VENDOR_<FOO>=n > > This reduces the size of the defconfig without any change in the > resulting kernel config. > > shmobile_defconfig Enhancements: > > * Set CONFIG_LOCALVERSION to shmobile_defconfig > > This follows what appears to be common practice in defconfigs > and allows easier management of the kernel flavour at run-time. I replied to the multi-versions of defconfig for this patch -- it's not a good way to solve the problem of detecting config at runtime. Please drop this patch. See: https://lore.kernel.org/lkml/CAOesGMgkU6yBRpAsED2fPyuAo9Tc=YprndGdkmBVrc+0783VwQ@mail.gmail.com/ -Olof
Hi Olof, On Sun, Jul 22, 2018 at 12:27 AM Olof Johansson <olof@lixom.net> wrote: > On Fri, Jul 20, 2018 at 02:03:54PM +0200, Simon Horman wrote: > > Please consider these Renesas ARM based SoC defconfig updates for v4.19. > > * Set CONFIG_LOCALVERSION to shmobile_defconfig > > > > This follows what appears to be common practice in defconfigs > > and allows easier management of the kernel flavour at run-time. > > I replied to the multi-versions of defconfig for this patch -- it's not a good > way to solve the problem of detecting config at runtime. Please drop this > patch. See: > > https://lore.kernel.org/lkml/CAOesGMgkU6yBRpAsED2fPyuAo9Tc=YprndGdkmBVrc+0783VwQ@mail.gmail.com/ One more comment to the rescue: it does complicate regression testing, as the test software running on the DUT has no easy way to distinguish between e.g. shmobile_defconfig and multi_v7_defconfig (and whatever other board-specific configs I use for testing). Yes, I can have these as local patches in my tree (of course I already have ;-), but when bisecting, I have to remember to (un)apply them in every step. Thanks! Gr{oetje,eeting}s, Geert
On Sat, Jul 21, 2018 at 03:03:43PM -0700, Olof Johansson wrote: > On Fri, Jul 20, 2018 at 02:03:54PM +0200, Simon Horman wrote: > > Hi Olof, Hi Kevin, Hi Arnd, > > > > Please consider these Renesas ARM based SoC defconfig updates for v4.19. > > > > > > The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40: > > > > Linux 4.18-rc1 (2018-06-17 08:04:49 +0900) > > > > are available in the git repository at: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-arm-defconfig-for-v4.19 > > > > for you to fetch changes up to e82c98d0448c60706a8024d460eadb9d7402dcba: > > > > ARM: multi_v7_defconfig: Enable support for RZN1D-DB (2018-07-13 10:15:20 +0200) > > > > ---------------------------------------------------------------- > > Renesas ARM Based SoC Defconfig Updates for v4.19 > > > > multi_v7_defconfig and shmobile_defconfig Enhancement: > > > > * Enable support for recently upstreamed RZN1D-DB board > > in multi_v7_defconfig and shmobile_defconfig. This is > > to give better test coverage. > > > > shmobile_defconfig Clean-Up: > > > > * Drop NET_VENDOR_<FOO>=n > > > > This reduces the size of the defconfig without any change in the > > resulting kernel config. > > > > shmobile_defconfig Enhancements: > > > > * Set CONFIG_LOCALVERSION to shmobile_defconfig > > > > This follows what appears to be common practice in defconfigs > > and allows easier management of the kernel flavour at run-time. > > I replied to the multi-versions of defconfig for this patch -- it's not a good > way to solve the problem of detecting config at runtime. Please drop this > patch. See: > > https://lore.kernel.org/lkml/CAOesGMgkU6yBRpAsED2fPyuAo9Tc=YprndGdkmBVrc+0783VwQ@mail.gmail.com/ Thanks, I'll repost this pull-request with that patch dropped.
On Mon, Jul 23, 2018 at 2:11 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > Hi Olof, > > On Sun, Jul 22, 2018 at 12:27 AM Olof Johansson <olof@lixom.net> wrote: >> On Fri, Jul 20, 2018 at 02:03:54PM +0200, Simon Horman wrote: >> > Please consider these Renesas ARM based SoC defconfig updates for v4.19. > >> > * Set CONFIG_LOCALVERSION to shmobile_defconfig >> > >> > This follows what appears to be common practice in defconfigs >> > and allows easier management of the kernel flavour at run-time. >> >> I replied to the multi-versions of defconfig for this patch -- it's not a good >> way to solve the problem of detecting config at runtime. Please drop this >> patch. See: >> >> https://lore.kernel.org/lkml/CAOesGMgkU6yBRpAsED2fPyuAo9Tc=YprndGdkmBVrc+0783VwQ@mail.gmail.com/ > > One more comment to the rescue: it does complicate regression testing, > as the test software running on the DUT has no easy way to distinguish > between e.g. shmobile_defconfig and multi_v7_defconfig (and whatever > other board-specific configs I use for testing). > Yes, I can have these as local patches in my tree (of course I already have ;-), > but when bisecting, I have to remember to (un)apply them in every step. Hi, It looks like scripts/setlocalversion will look for files named localversion* in the directory you build in, git won't touch the file so you don't have to re-apply it every time. I do see the usefulness for bisect and so on, but there's such a high chance that people will start changing configs without changing localversion that the value of it will diminish immediately for downstream trees. Also, the "local" in localversion sort of indicates that it shouldn't be set in a central place. :) -Olof
Hi Olof, On Mon, Jul 23, 2018 at 6:22 PM Olof Johansson <olof@lixom.net> wrote: > On Mon, Jul 23, 2018 at 2:11 AM, Geert Uytterhoeven > <geert@linux-m68k.org> wrote: > >> > * Set CONFIG_LOCALVERSION to shmobile_defconfig > >> > > >> > This follows what appears to be common practice in defconfigs > >> > and allows easier management of the kernel flavour at run-time. > >> > >> I replied to the multi-versions of defconfig for this patch -- it's not a good > >> way to solve the problem of detecting config at runtime. Please drop this > >> patch. See: > >> > >> https://lore.kernel.org/lkml/CAOesGMgkU6yBRpAsED2fPyuAo9Tc=YprndGdkmBVrc+0783VwQ@mail.gmail.com/ > > > > One more comment to the rescue: it does complicate regression testing, > > as the test software running on the DUT has no easy way to distinguish > > between e.g. shmobile_defconfig and multi_v7_defconfig (and whatever > > other board-specific configs I use for testing). > > Yes, I can have these as local patches in my tree (of course I already have ;-), > > but when bisecting, I have to remember to (un)apply them in every step. > > It looks like scripts/setlocalversion will look for files named > localversion* in the directory you build in, git won't touch the file > so you don't have to re-apply it every time. Thanks a lot, works fine! I didn't know about that; I started using CONFIG_LOCALVERSION during the version control dark ages. Since I use different output directories for different builds anyway, the file won't ever be removed by git. Gr{oetje,eeting}s, Geert