From owner-freebsd-arm@FreeBSD.ORG Thu Mar 7 00:15:55 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 843E3236 for ; Thu, 7 Mar 2013 00:15:55 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by mx1.freebsd.org (Postfix) with ESMTP id 4CA48378 for ; Thu, 7 Mar 2013 00:15:55 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id k14so13231363oag.39 for ; Wed, 06 Mar 2013 16:15:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=oZaaaRfsZmyAIu64mjfNbKUgGREeGIltPp6sY+7Ynak=; b=QE1m8Wf/rtfZcyYhZimHptRmJhrrX8yrNxybf2Ip5KPCjXeMi4LuSrABBLTDR3ttyR U/6uLeyjUnc/Z+N2IXaQvG0+KMcP2Z+V0kCwHswqhev63tQ/PRHX58B1h9E3cY4MDOqc kT5kn0FtNtdUxhOmp1IqGv8bZ99LXS5nsBYB45UFU0K6kkH/MKJzy0zQGempqIIKIBw7 cLwgfZryhjn4NCQ4HSnrR0fyoEBCZlXbNKxcWIR4sdKH1Q4ryyPL/Usvi7vowyc3n5EI nGbuFBiyUtrRjud748Dlmiqx+Q/UXyC/AlpeIhTwrAeJ+590+AxRTc7+LV/HbWhp5ZPg 9rrA== X-Received: by 10.182.43.103 with SMTP id v7mr24396219obl.17.1362615354719; Wed, 06 Mar 2013 16:15:54 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id z5sm41024645oeh.1.2013.03.06.16.15.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Mar 2013 16:15:53 -0800 (PST) Sender: Warner Losh Subject: Re: GENERIC kernel issues Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130307014021.3c02fdb4.ray@freebsd.org> Date: Wed, 6 Mar 2013 17:15:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5EF158CC-645A-466C-BDF7-7CA04B1CEA10@bsdimp.com> References: <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> <20130306234004.bf113967.ray@freebsd.org> <4C0099FA-BBBE-4F93-8C97-CE5B79465829@bsdimp.com> <20130307005649.35a6b9ae.ray@freebsd.org> <20130307014021.3c02fdb4.ray@freebsd.org> To: Aleksandr Rybalko X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlADPMKmw8d9+T0r4uxjC0RdasmCre4A9UQp2SIM3PiuCHoyzYHXLLllAUneZAmN/Rh6Wqe Cc: freebsd-arm@freebsd.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 00:15:55 -0000 On Mar 6, 2013, at 4:40 PM, Aleksandr Rybalko wrote: > On Wed, 6 Mar 2013 15:16:02 -0800 > Adrian Chadd 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=