From owner-freebsd-bugs@FreeBSD.ORG Wed Aug 2 14:53:51 2006 Return-Path: X-Original-To: bugs@FreeBSD.ORG Delivered-To: freebsd-bugs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3157A16A4DD; Wed, 2 Aug 2006 14:53:51 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D41043D72; Wed, 2 Aug 2006 14:53:50 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k72Eq2sa066348; Wed, 2 Aug 2006 08:52:02 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 02 Aug 2006 08:52:02 -0600 (MDT) Message-Id: <20060802.085202.74685303.imp@bsdimp.com> To: henrik@brixandersen.dk From: Warner Losh In-Reply-To: <20060802140628.GL17004@osgiliath.opasia.dk> References: <20060802.073232.-494097392.imp@bsdimp.com> <17702.1154526225@critter.freebsd.dk> <20060802140628.GL17004@osgiliath.opasia.dk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Wed, 02 Aug 2006 08:52:03 -0600 (MDT) Cc: bugs@FreeBSD.ORG, phk@phk.freebsd.dk, freebsd-embedded@FreeBSD.ORG Subject: Re: misc/101228: [nanobsd] [patch] Two more entries for FlashDevice.sub X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2006 14:53:51 -0000 From: Henrik Brix Andersen Subject: Re: misc/101228: [nanobsd] [patch] Two more entries for FlashDevice.sub Date: Wed, 2 Aug 2006 16:06:28 +0200 > On Wed, Aug 02, 2006 at 01:43:45PM +0000, Poul-Henning Kamp wrote: > > I'm afraid I have to agree with Warner here. > > > > I was hoping that the vendors would standardize on a limited number > > of geometries, but it seems that yet again my faith in the wisdom > > of hardware vendors is not supported by evidence. > > So what should happen with the existing entries in FlashDevice.sub? > Should we deprecate it alltogether - or leave it as a half-baked > solution? In our operation, we burn each flash from a tarball after taking that flash's geometry into account. This allows us to get the maximium amount of space on our 'hog' partitions, but does mean we don't put an actual image onto the part. We don't use nanobsd, btw, since our solution is home-grown before nanobsd was even thought of by phk. nanobsd is an image based solution, so it should pick numbers that are a little smaller than the typical part (eg use 510,000 bytes for the size of the image of a 512MB flash) and use those for everything. Nanobsd is not setup to optimize to a level higher than this. Warner