From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c0b::242; helo=mail-it0-x242.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id C557421122934 for ; Thu, 6 Sep 2018 07:31:23 -0700 (PDT) Received: by mail-it0-x242.google.com with SMTP id x79-v6so19899000ita.1 for ; Thu, 06 Sep 2018 07:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=j/M0AQq9lCKvWtPNL5d15DaCffmHn9XaRh12+/KJZnM=; b=fNFGWvKAoWzWet9P3CREeI3c2P1N/j2roVbBN/QbULQJdM2pq8adzogEEkTtB6jcVe tAIYDGKfbI+G85ioqvVFXIe6YAtnl7EItGfktU8zK6Kv8tGfzwrCWdNT7lVcORAohaYk D/vuRq0NuXxpAptrON++E8hWuC6nN3iqPG9v0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=j/M0AQq9lCKvWtPNL5d15DaCffmHn9XaRh12+/KJZnM=; b=pnvbdRUzLkZGywASZ3tUNEdllwmy5hUr7zRsBrdH8IgLjU7RfnS1MovoOPhhUspsDa /tXIDocklXUXFY5ZOvoKbczv6YiTPql23zBvkPhLt8SyrRYQOovKGsWPFD2CqLWKPJmx QuB11MFdxxP5OCrAAzQMJZir4J5gCy+qLmVLOGGT04WXS3VkJZ6ZKhlnPxttVoTPZjmj 9cEvCiS7/quRG/4zWdxR7EMxISEhBQ2NkgbxUqskaYOTcydAKKCIfUlEvPHFzxuvOW5n XhUCVNr5yCOlryptrJ+4UmLGT+U8DYZUIBA4CxQrmDwnt08TsdCr8dthWZEH68eyPaVQ kz3g== X-Gm-Message-State: APzg51CyBTGAQzFTWXcfncNwcWjEYuBsVZFmvx+AEjvwNS/17oH3IVSG KgE6/YaOZQdXJz6QeoulwJmpNbjQc2t67zJJswKeEg== X-Google-Smtp-Source: ANB0VdZ3HpjW6LJpnxPRoEUKaVZlXynf3oPa4AeIcMvKGHUqSIluz02ATZvn0XRjGdQqRYumYJ0pE4uYJfWyAW01Nrs= X-Received: by 2002:a02:1515:: with SMTP id j21-v6mr2408537jad.2.1536244282621; Thu, 06 Sep 2018 07:31:22 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:1c06:0:0:0:0:0 with HTTP; Thu, 6 Sep 2018 07:31:22 -0700 (PDT) In-Reply-To: References: <1535950443-27106-1-git-send-email-mw@semihalf.com> <1535950443-27106-2-git-send-email-mw@semihalf.com> From: Ard Biesheuvel Date: Thu, 6 Sep 2018 16:31:22 +0200 Message-ID: To: Marcin Wojtas Cc: edk2-devel-01 , Leif Lindholm , Nadav Haklai , "jsd@semihalf.com" , Grzegorz Jaszczyk , Tomasz Michalec Subject: Re: [platforms: PATCH 1/7] Silicon/SynQuacer/PlatformDxe: Modify initialization of SdMmcOverride X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 14:31:24 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 6 September 2018 at 16:26, Marcin Wojtas wrote: > czw., 6 wrz 2018 o 16:04 Ard Biesheuvel napis= a=C5=82(a): >> >> On 3 September 2018 at 06:53, Marcin Wojtas wrote: >> > From: Tomasz Michalec >> > >> > This patch changes way the EDKII_SD_MMC_OVERRIDE protocol >> > sturcture is allocated. Using AllocateZeroPool and then >> > seting callbacks in the structure allow driver to be immune to >> > adding new callbacks in SdMmcOveride protocol in future. >> > >> >> What is the point of this patch? >> >> Statically allocating the structure will zero initialize the members >> that are not initialized explicitly, but only the members that are >> known to exist at compile time. >> > > In such case this patch is really not needed. > >> I guess the idea of this patch is to work around the latter >> limitation, but unfortunately, using sizeof(EDKII_SD_MMC_OVERRIDE) >> puts you in the exact same situation. > > If the newly added callback are zero-initialized, the situation is > fine as they won't be executed. > Yes, but this patch does not change that situation at all. So please, explain which problem is fixed by this patch? >> >> This is the reason I added the version field. New hooks should only be >> added after incrementing the version, and calling the new hooks should >> only occur if the runtime version of the protocol implementation is >> greater than or equal to the version where those hooks were first >> introduced. >> > > So even if the given SdMmcOverride protocol callback will be NULL for > Synquacer controller, is there still a risk that anything could be > broken without the version check? > Yes. In EDK2, you can combine binary drivers with drivers build from source. If a binary driver was built against an older version of the SdMmcOverride header, it may have non-NULL values in the locations of the new methods. This patch does not help against that scenario.