Date: Wed, 18 Apr 2012 13:47:59 -0400 From: John Baldwin <jhb@freebsd.org> To: Andriy Gapon <avg@freebsd.org> Cc: freebsd-fs@freebsd.org, Ian Lepore <freebsd@damnhippie.dyndns.org>, freebsd-hackers@freebsd.org Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool Message-ID: <201204181347.59109.jhb@freebsd.org> In-Reply-To: <4F8ED702.4020803@FreeBSD.org> References: <4F8999D2.1080902@FreeBSD.org> <1334760007.1082.243.camel@revolution.hippie.lan> <4F8ED702.4020803@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, April 18, 2012 11:00:18 am Andriy Gapon wrote: > on 18/04/2012 17:40 Ian Lepore said the following: > > 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. > > Right, but where the flag would reside? > And how the older code that is not aware of the new flag would cope with the new > layout? I think the size should be appended to the end of the current structure. However, it will buy us more flexibility in the future. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201204181347.59109.jhb>