From owner-freebsd-arch@FreeBSD.ORG Wed Oct 14 00:32:34 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0684D106566C for ; Wed, 14 Oct 2009 00:32:34 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id 7D8318FC1B for ; Wed, 14 Oct 2009 00:32:33 +0000 (UTC) Received: from c122-107-125-150.carlnfd1.nsw.optusnet.com.au (c122-107-125-150.carlnfd1.nsw.optusnet.com.au [122.107.125.150]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n9E0WP8I026922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Oct 2009 11:32:27 +1100 Date: Wed, 14 Oct 2009 11:32:25 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: "M. Warner Losh" In-Reply-To: <20091013.113451.2056345767.imp@bsdimp.com> Message-ID: <20091014103634.A6350@delplex.bde.org> References: <200910130043.n9D0hVCr089970@svn.freebsd.org> <20091013.113451.2056345767.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: gonzo@FreeBSD.org, arch@FreeBSD.org Subject: Re: svn commit: r198009 - projects/mips/sbin X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 00:32:34 -0000 On Tue, 13 Oct 2009, M. Warner Losh wrote: > In message: <200910130043.n9D0hVCr089970@svn.freebsd.org> > Oleksandr Tymoshenko writes: > : Log: > : - Enable fdisk build for MIPS > > I'm starting to think that the right answer here is to enable fdisk > for all platforms. Of course. fdisk is MI except for bugs in it. It should be usable on any system to manage disks or disk images created on any system that needs it natively. fdisk certainly has bugs like assuming that the host system byte order is the same as the target system byte order. It fails on big-endian systems because the target system byte order is always little-endian. Its device independence was broken using g_device_path() just over 1 year ago, so it no longer works on disk images (except possibly if. Older geom breakage is still handled benignly by not aborting when fdisk is run on a system or file that doesn't support geom ioctls (it even has a comment about this, but g_device_path() fails long before the working code is reached). Bruce