From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 2FE1D1A1DF5 for ; Fri, 5 Aug 2016 12:03:31 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A017D80F6B; Fri, 5 Aug 2016 19:03:30 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-116.phx2.redhat.com [10.3.116.116]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u75J3Rbo004502; Fri, 5 Aug 2016 15:03:27 -0400 To: "Cohen, Eugene" , Larry Cleeton , "Ye, Ting" , "edk2-devel@lists.01.org" References: From: Laszlo Ersek Message-ID: <6be427bf-21d9-207d-f504-4946d4fe07f4@redhat.com> Date: Fri, 5 Aug 2016 21:03:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Fri, 05 Aug 2016 19:03:30 +0000 (UTC) Subject: Re: Breaking change issue with NetworkPkg/Ip6Dxe/Ip6ConfigImlp.[c, h] X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 19:03:31 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 08/05/16 18:12, Cohen, Eugene wrote: > We've been hit by this same kind of issue and it's really painful, especially as it affects shipping systems. > > Long term I think we need an extensible/revisioned data format so we can get forwards and backwards compatibility between NVRAM data and FW. In OVMF we have a (very rudimentary) implementation for this, see PlatformConfigLoad() in "OvmfPkg/PlatformDxe/PlatformConfig.c". The idea is shamelessly stolen from UEFI protocols: - we store the config structure in some NV variable under some namespace GUID, - new fields can only be added after existing fields to the structure, - if a new field would change the meaning of a preexistent field, or some preexistent fields would have to be dropped / replaced, then the change is deemed incompatible, and a new variable name or namespace GUID is required. The number of bytes the config reader function reads from the variable is the minimum of: (a) the size of the variable, (b) the size of largest structure version known to the config reader. If a==b, then it's a version match. If a>b, then it's a firmware downgrade (unknown fields are ignored). If a