Date: Wed, 18 Apr 2012 18:00:18 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Ian Lepore <freebsd@damnhippie.dyndns.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: <4F8ED702.4020803@FreeBSD.org> In-Reply-To: <1334760007.1082.243.camel@revolution.hippie.lan> 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> <1334760007.1082.243.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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? -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F8ED702.4020803>