Date: Tue, 03 Oct 2017 16:10:09 -0600 From: Ian Lepore <ian@freebsd.org> To: Warner Losh <imp@bsdimp.com>, lausts@acm.org Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: GENERIC kernel (was Re: BeagleBone Crochet Build Problem) Message-ID: <1507068609.86205.81.camel@freebsd.org> In-Reply-To: <CANCZdfr%2B7Kpz5Qqz46NHWV=9PgNGhf7nDo4m3UxN1pA6fzgjSA@mail.gmail.com> References: <176dbdd5-1a32-06b2-7dd8-0647cc0fbe20@acm.org> <1506954050.22078.55.camel@freebsd.org> <CABx9NuS9XAfWNHM1fAFKV8byhWyv=jXS_W%2BNO3Y6s-CtEQdp6A@mail.gmail.com> <1506962766.22078.69.camel@freebsd.org> <20171003170053.GB2918@lonesome.com> <8eb57091-0b6f-3f0a-8c80-997b951a383f@acm.org> <CANCZdfr%2B7Kpz5Qqz46NHWV=9PgNGhf7nDo4m3UxN1pA6fzgjSA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2017-10-03 at 14:55 -0600, Warner Losh wrote: > On Tue, Oct 3, 2017 at 2:03 PM, Thomas Laus <lausts@acm.org> wrote: > > > > > On 10/03/17 13:00, Mark Linimon wrote: > > > > > > On Mon, Oct 02, 2017 at 10:46:06AM -0600, Ian Lepore wrote: > > > > > > > > Why are we working towards a GENERIC kernel for arm? > > > My intuition would be: > > > > > > - easier to tell new FreeBSD users how to start > > > - less work for Release Engineering to make targets > > > > > > OTOH I'm not doing the work so I don't get to set the > > > direction :-) > > > > > > My _opinion_ is that we still seem to have a steeper > > > curve for our new users than is necessary. I intend to > > > think about that more this fall. > > > > > That is probably 'wishful thinking' for the very distant future. Most > > of the common ARM SOC's have very different capabilities between each > > other. Each also requires a unique U-Boot partition that gets read > > before the FreeBSD kernel is loaded. > > > While this is true, how to create them can be described generically. You > put these bits in this physical location, or on that partition and away you > go. The pre-boot environment is indeed different, but it's highly desirable > to have everything after that identical. It ensures uniformity in a highly > fragmented segment of our user base. Different kernels, even generated from > the same sources, run the risk of being subtly different from each other, > leading to less coverage between the boards. We've had issues related to > this in the past from time to time. > > I'm working on a program I'm calling "spin" which will take a description > of what to use (eg, u-boot for the banana ramma board plus FreeBSD 12.3R) > and it will create a bootable image knowing nothing more. If it also has to > know which of a bazillion kernels to use, that makes things more > complicated. > > We want more uniformity, not less. Much of the differences we have today > are arbitrary (and often wrong). > > > > > > I strongly favor the current approach that has a custom kernel > > configuration file and U-Boot for each SOC. All of the common ARM > > systems have a limited amount of real estate to store FreeBSD kernel and > > base system because it all must fit on a SD memory card. Having a > > GENERIC kernel that covers all SOC variants would consume flash space > > that will never be used. > > Nobody is saying that you can't do this. Just that GENERIC will be the > union of all these kernel and be what you get by default. Since nobody has > quantified the differences, I'm having trouble getting worked up over the > somewhat trivial difference in size (especially compared to most SD cards > today). > > Warner Well, I guess I'll stop pretending there's any chance this freight train can be stopped. I find the advantages mentioned so far dubious at best, specious at worst, except for the single item "packaged base". I don't know much about how that stuff is structured, but I can see how having lots of different kernels might be difficult for packaging. But we absolutely have to solve the problem of making it easy for people to create custom kernel configs. "Include GENERIC and add some nodevice/nooption lines" is just not going to work. Right now I use "include IMX6" and then some nodevice/nooption lines, and that works fine. So if IMX6 goes away as a standalone buildable config, there needs to be some other thing like it that can be included. The idea that keeps nudging me is that our GENERIC should look like: include std.armv6 include std.armdebug include std.a10 include std.a20 include std.bcm2835 include std.imx6 ... Now anybody can create a custom config by including std.armv6, std.armdebug if they want it, and their soc's std file. (The std.armdebug is also for re@, so that it's easy for them to adjust when making releases.) The problem is that I'm so backed up with other obbligations and problem reports not getting dealt with and of course $work, so I never find any time to give a scheme like this a try. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1507068609.86205.81.camel>