Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 12 Apr 2019 03:50:45 -0700 (PDT)
From:      "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>
To:        Emmanuel Vadot <manu@bidouilliste.com>
Cc:        Svatopluk Kraus <onwahe@gmail.com>, Emmanuel Vadot <manu@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r346096 - head/sys/arm/conf
Message-ID:  <201904121050.x3CAoj7i075998@gndrsh.dnsmgr.net>
In-Reply-To: <20190412120950.dd0aae47e93ba7b50aaa47c6@bidouilliste.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> 
>  Hi Svatopluk,
> 
> On Thu, 11 Apr 2019 21:23:35 +0200
> Svatopluk Kraus <onwahe@gmail.com> wrote:
> 
> > I understand the reason for GENERIC. But are we so blind that we will
> > delete everything that is not GENERIC? In other words, why to delete
> > nice specific KERNEL configurations for boards we support when only
> > reason I see is that GENERIC is so cool for some people?
> 
>  That's simple and maybe I should have explain more in the commit
> message. Those configs aren't tested. All the images that we provide
> are using GENERIC kernel so we know that GENERIC is tested (somewhat).
>  Those config will also lack update if we need to add a new required
> pseudo device (like syscon) and maybe it's already the case on some.
>  The only way (for now) that we could produce board specific kernel
> is to include GENERIC and add a bunch of nodevice "blah", which is not
> going to happen. We have plan for splitting the GENERIC kernel into soc
> familly file, then it would be easier for people to have a SoC kernel
> config.
>  Finaly I guess that when you say "boards we support" you are talking
> about RPI2, BEAGLEBONE or maybe PANDABOARD. For me those aren't board
> that we support, those are survivors that had the chance to not die in
> the past years. No developer care about or work on those boards.

I just recently asked about the issue I was having when I last
tried to run
	head/sys/arm/conf/CHROMEBOOK-SNOW
which iirc is a derived from
	head/sys/arm/conf/EXYNOS5420
which is documented in the Wiki as to how to build it,
pointing to use the kernel config you just deleted.

> > Svatopluk Kraus
> > 
> > 
> > 
> > On Wed, Apr 10, 2019 at 9:27 PM Emmanuel Vadot <manu@freebsd.org> wrote:
> > >
> > > Author: manu
> > > Date: Wed Apr 10 19:27:14 2019
> > > New Revision: 346096
> > > URL: https://svnweb.freebsd.org/changeset/base/346096
> > >
> > > Log:
> > >   arm: kernel: Remove old kernel configs
> > >
> > >   Follow up to r346095
> > >   All those kernels are either not working or the release have switched
> > >   to GENERIC
> > >
> > > Deleted:
> > >   head/sys/arm/conf/AML8726
> > >   head/sys/arm/conf/BEAGLEBONE
> > >   head/sys/arm/conf/CHROMEBOOK
> > >   head/sys/arm/conf/CHROMEBOOK-PEACH-PIT
> > >   head/sys/arm/conf/CHROMEBOOK-PEACH-PIT.hints
> > >   head/sys/arm/conf/CHROMEBOOK-SNOW
> > >   head/sys/arm/conf/CHROMEBOOK-SPRING
> > >   head/sys/arm/conf/CHROMEBOOK.hints
> > >   head/sys/arm/conf/EXYNOS5.common
> > >   head/sys/arm/conf/EXYNOS5250
> > >   head/sys/arm/conf/EXYNOS5420
> > >   head/sys/arm/conf/ODROIDC1
> > >   head/sys/arm/conf/PANDABOARD
> > >   head/sys/arm/conf/PANDABOARD.hints
> > >   head/sys/arm/conf/RADXA
> > >   head/sys/arm/conf/RADXA-LITE
> > >   head/sys/arm/conf/RK3188
> > >   head/sys/arm/conf/RPI2
> > >
> 
> 
> -- 
> Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
> 
> 

-- 
Rod Grimes                                                 rgrimes@freebsd.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201904121050.x3CAoj7i075998>