Date: Wed, 18 Apr 2012 08:40:07 -0600 From: Ian Lepore <freebsd@damnhippie.dyndns.org> To: Andriy Gapon <avg@FreeBSD.org> Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org, John Baldwin <jhb@FreeBSD.org> Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool Message-ID: <1334760007.1082.243.camel@revolution.hippie.lan> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 :-) > Code would only assume the new field was at the front of the struct if the new flag is set, otherwise it would use the historical struct layout. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1334760007.1082.243.camel>