From owner-freebsd-arm@FreeBSD.ORG Thu Mar 7 00:09:09 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8E880173 for ; Thu, 7 Mar 2013 00:09:09 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5736A344 for ; Thu, 7 Mar 2013 00:09:09 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id l20so13608209oag.9 for ; Wed, 06 Mar 2013 16:09:08 -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=sOTeOHCnU3OkyCVf8iAaBDdQ/3gsHVTDhLPlEqMb1Bk=; b=bjo9MW1UGEu8Sq3agqSMFm8dFfCqT5Mgpo6Cas4HwFtW5GUGGH4eL0oCNwlLeBD9Q6 BBW7DgSq836QIECMXNoYKUeCILx84/IX0Fob5ytWyic09z0zjOSVHcdcxv4OM/eWOq9Y mpNV+Do9FonypEutT6PNwcqw+vztKIWQUHAAn0xqvrdIAfzNTcOc/vOwu0tksTGNhNVU EgyZ9im4Adt9T7K90MivL9SjON3N5xRs2S3XQEaD9DJotVxRkjUdPru9QIO39hWykEo7 5FzTARUPk9Jl3Zl2bK2md509ulgy0wgo1cp0i+a/2dNyA8MvPYShVz5ph6PrDfRdMR3O OFkA== X-Received: by 10.60.22.34 with SMTP id a2mr24268908oef.97.1362614948539; Wed, 06 Mar 2013 16:09:08 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id ad19sm41003796oec.0.2013.03.06.16.09.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Mar 2013 16:09:07 -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:09:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: 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: ALoCoQmz12nAOMpE63Cp7kt6S5U4BKhssSu4dcl7LbpUd+pcThRBS35YlKo4UhorGiU3Jo8FB3nP 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:09:09 -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. We're also not talking about making it too complicated, but rather the = reverse: how can we create fewer binary images. Since Linux is king in = the embedded world, it seems self obvious that having our kernels be = compatible with that will give us the least head wind. Having attempted = to do something "right" without considering the prevailing environment = before, I'd say that we will be miles ahead doing this in a sane way = first, rather than kludging something together that kinda works on two = boards. Today a single linux arm kernel will boot on hundreds if not = thousands of different boards. We should learn from that experience = rather than coming up with something that's NIH, but gets "something" = done fast. So far we haven't been hampered by taking this route, apart from some = churn in email and the odd issue here and there. Ian has been hitting it = out of the park, and none of the issues we've seen so far are show = stoppers, especially if we go to a static PIC ubldr to increase the = number of systems we can load on... Then what we do with the elf = headers suddenly doesn't matter at all. Or at least not as much... Warner=