Date: Wed, 6 Mar 2013 17:15:50 -0700 From: Warner Losh <imp@bsdimp.com> To: Aleksandr Rybalko <ray@freebsd.org> Cc: freebsd-arm@freebsd.org, Ian Lepore <ian@freebsd.org> Subject: Re: GENERIC kernel issues Message-ID: <5EF158CC-645A-466C-BDF7-7CA04B1CEA10@bsdimp.com> In-Reply-To: <20130307014021.3c02fdb4.ray@freebsd.org> References: <DF7B73D4-BE50-4E75-8D5B-FE19A4764F31@freebsd.org> <1362445777.1195.299.camel@revolution.hippie.lan> <3DFABC9A-876A-4F34-9E15-E4C630D7B077@bsdimp.com> <1362542286.1291.94.camel@revolution.hippie.lan> <4CF23AFE-DD69-40AA-ACFB-46F055F0AA3F@bsdimp.com> <1362594744.1291.132.camel@revolution.hippie.lan> <DDB2A45D-33E4-4612-A17B-62F57EBCDFD0@bsdimp.com> <20130306234004.bf113967.ray@freebsd.org> <4C0099FA-BBBE-4F93-8C97-CE5B79465829@bsdimp.com> <20130307005649.35a6b9ae.ray@freebsd.org> <CAJ-VmokWKcogM%2BJFWn%2B%2Brw6kn85xw-5wGeiV2yiS9upidXBvSA@mail.gmail.com> <20130307014021.3c02fdb4.ray@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 6, 2013, at 4:40 PM, Aleksandr Rybalko wrote: > On Wed, 6 Mar 2013 15:16:02 -0800 > Adrian Chadd <adrian@freebsd.org> wrote: >=20 >> Peeps, >>=20 >> If you make the boot process too complicated and it stops being "load >> kernel via flash/NFS, boot" then people may just not bother. :-) >>=20 >> I know you're going for correctness and we're hampered by how "linux >> does things', but I really do suggest that you first get working, >> packaged, easily installed and updated systems using what we = currently >> heave before you try to make a 'much nicer but noone ever uses it' >> solution. >>=20 >> Please don't fall down the trap of "over-engineering correctness that >> noone will ever use." that software people do when they don't have >> deliverables. >>=20 >> 2c, >>=20 >>=20 >>=20 >> Adrian >=20 > Adrian,=20 >=20 > I hope you don't compile special kernel before first boot on > every new laptop/desktop/server? :))) >=20 > We want also find such drugs for so mach fancy ARM world, so anybody > will have a way to boot board with one of few install images, but not > one per board. another way of saying this is that the commercial folks that have been = using ARM boards have discovered that a diversity of kernels is bad, and = the more boards one kernel can support the better for their support = load. Also, we've been down the compile it per board route, and it is = showing signs of strain. Linux also went down this route years ago and = found the strain too much so has been evolving into a single kernel = image that supports any FDT platform. We're a ways away from *THAT*, but = one of the issues that needs to be solved is loading stuff in the right = place, and Ian is well down that path and should have a solution to = that. Then all we have to worry about are things like DELAY, cpu_*, = platform_*, cache coherence differences (currently ifdefs in pmap v6 = code), switching between v4/5 and v6/7 pmap, and likley a few others = that I've forgotten. All these things today make a single image = impossible. But it is a solveable, whack-a-mole problem rather than an = infinite set of things we have to struggle with. So while we're not trying to stop someone from having a custom kernel, = we're trying to have a viable GENERIC that actually works like x86 and = ppc do today, hopefully without a big performance hit.... Should we = succeed, then you can still build a specific thing, should we fail, you = can still build a specific thing... But if we succeed you won't be = forced to do so... Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5EF158CC-645A-466C-BDF7-7CA04B1CEA10>