From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 18 14:41:38 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2E4AD1065676 for ; Wed, 18 Apr 2012 14:41:38 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id 0E5548FC12 for ; Wed, 18 Apr 2012 14:41:38 +0000 (UTC) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta06.emeryville.ca.mail.comcast.net with comcast id zSNf1i0050lTkoCA6ShYJ8; Wed, 18 Apr 2012 14:41:32 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta04.emeryville.ca.mail.comcast.net with comcast id zShX1i00q4NgCEG8QShY42; Wed, 18 Apr 2012 14:41:32 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q3IEfTIg066978 for ; Wed, 18 Apr 2012 08:41:29 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: freebsd-hackers@freebsd.org In-Reply-To: <4F8ED187.9030108@FreeBSD.org> References: <4F8999D2.1080902@FreeBSD.org> <201204171643.39447.jhb@freebsd.org> <4F8E58EE.8080909@FreeBSD.org> <201204180941.24699.jhb@freebsd.org> <1334758943.1082.242.camel@revolution.hippie.lan> <4F8ED187.9030108@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Apr 2012 08:41:29 -0600 Message-ID: <1334760089.1082.245.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 14:41:38 -0000 On Wed, 2012-04-18 at 17:36 +0300, Andriy Gapon wrote: > on 18/04/2012 17:22 Ian Lepore said the following: > > YES! A size field (preferably as the first field in the struct) along > > with a flag to indicate that it's a new-style boot info struct that > > starts with a size field, will allow future changes without a lot of > > drama. It can allow code that has to deal with the struct without > > interpretting it (such as trampoline code that has to copy it to a new > > stack or memory area as part of loading the kernel) to be immune to > > future changes. > > Yeah, placing the new field at front would immediately break compatibility and > even access to the flags field :-) > Oh wait, is the flags field embedded in the struct? My bad, I didn't look. In the ARM code I'm used to working with, the flags are passed from the bootloader to the kernel entry point in a register; I don't know why assumed that would be true on other platforms. -- Ian