From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web12.974.1662137363264779662 for ; Fri, 02 Sep 2022 09:49:23 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=iiC8l/qN; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1662137362; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MdlgN94/NRbWtICuIgNjYFifrhiWFX3R/fci4GoWdx4=; b=iiC8l/qNsfFxSJ+ATB9ILWFqBt2YYwlARXOHHajb8Bo+caltd1W6cjKrFcTEySJcihuhbs bb3g2fYqaM2O4q+cq/V5qCIsynl2EEkkEa9p5cp+oeFKE/oHJs0lIkbFDQlxxnM6So0eCN 3PQ/cuyymWvBHcoCXUxBGZ0/dSvHtkk= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-669-4arch-vRMqi8dxHa1jxxXw-1; Fri, 02 Sep 2022 12:49:19 -0400 X-MC-Unique: 4arch-vRMqi8dxHa1jxxXw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A81578037AE; Fri, 2 Sep 2022 16:49:18 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.195.70]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 358EF40B40C7; Fri, 2 Sep 2022 16:49:18 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id C2E1B180039D; Fri, 2 Sep 2022 18:49:13 +0200 (CEST) Date: Fri, 2 Sep 2022 18:49:13 +0200 From: "Gerd Hoffmann" To: =?utf-8?B?VGjDqW8=?= Jehl Cc: devel@edk2.groups.io, Leif Lindholm , Michael D Kinney , Isaac Oram , Pedro Falcato , Stefan Hajnoczi Subject: Re: [edk2-platforms][PATCH v1 01/02] QemuOpenBoardPkg: Add QemuOpenBoardPkg Message-ID: <20220902164913.6mj6qrihcicriik6@sirius.home.kraxel.org> References: <20220827000201.22235-1-theojehl76@gmail.com> <20220827000201.22235-2-theojehl76@gmail.com> <20220902100245.m5mgcpvub4gmwj54@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, > > That is a rather short description for a patch of this size. It > > probably makes sense to break that down into smaller pieces and make a > > patch series out of it because you can describe the specific pieces much > > better then. > I was thinking about breaking down the main patch into smaller ones > corresponding to MinPlatform stages implementations to make it easier > to follow along. Sounds good. Also one patch per board-specific library or module makes things easier to review. > > Why duplicate that lib instead of just using the OvmfPkg version (which > > you do elsewhere)? > It was supposed to be for training purposes, > > Note that OvmfPkg got a PlatformInitLib recently which you might be able > > to use to reduce code duplication (didn't check the code though and > > maybe MinPlatform init is different enough that this doesn't help much). > For both GSOC purposes and MinPlatform compliance, I didn't want this > package to be OVMF but repacked, PlatformInit from OVMF is very > complete, maybe too much when we are targeting a simple board port. > QemuOpenBoardPkg's PlatformInit only performs the necessary and > nothing more, to make reading and understanding the package easier. > It's also up to debate, but concerning OVMF code, all the dependencies > we have with OVMF makes understanding the boot flow a bit harder, Ok. Having small & self-contained modules is nice for training and learning purposes. The many modules and libraries OVMF has provide more features and help reduce code duplication, but at times makes it indeed hard to follow the code control flow. So if the goal is to have a rather minimal qemu board for training purpose (and not duplicate all features OVMF has) I think I'm fine with the approach taken. > I was thinking about slowly phasing out OVMF modules with lot of > external dependencies in favor of new ones, Which ones do you have in mind specifically? I think it makes sense to continue sharing the drivers (virtio, gop, ...), but those should not have many external dependencies. take care, Gerd