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 EF9701A1EE6 for ; Wed, 5 Oct 2016 14:48:56 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (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 4A5AF3D946; Wed, 5 Oct 2016 21:48:56 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-104.phx2.redhat.com [10.3.116.104]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u95LmsWK021964; Wed, 5 Oct 2016 17:48:54 -0400 To: "Kinney, Michael D" , Andrew Fish , Daniil Egranov References: <93F01BC9-4B02-467E-B900-65C6775BB0F3@apple.com> <6ac805ec-66c2-a291-7852-3429efa018cd@arm.com> <9F98A80B-A3F4-4956-9D84-33C166384EB6@apple.com> Cc: "Carsey, Jaben" , edk2-devel-01 , Leif Lindholm From: Laszlo Ersek Message-ID: Date: Wed, 5 Oct 2016 23:48:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Wed, 05 Oct 2016 21:48:56 +0000 (UTC) Subject: Re: Assert in ShellPkg with latest tianocore edk2 source on the Reference Platform 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: Wed, 05 Oct 2016 21:48:57 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 10/05/16 23:34, Kinney, Michael D wrote: > Laszlo, > > There are many types of UEFI Drivers and they are enumerated in the > UEFI Driver Writer's Guide. Some follow the UEFI Driver Model and > some do not. > > A driver that only consumes/produces UEFI services/protocols without a depex > should be a UEFI Driver. If there is a depex or use of any PI services/protocols > then it must be one of the DXE driver types. > > We actually prefer to categorize drivers as UEFI Driver's if possible, because > that maximizes the drivers's compatibility with UEFI conformant platforms. Thanks! It's been a while since I last looked at that part of the guide (chapter 6, UEFI Driver Categories). I guess EnglishDxe then qualifies as a Service Driver. ... Interestingly, when people asked about automatically running applications (not drivers) for various kinds of init work, without staying resident, I occasionally thought about recommending a driver module that would return an error code intentionally, even on success. And now I see there's actually a category of drivers for this, called "Initializing Drivers". So now I wonder why we needed SysPrep#### after all... Probably because their order had to be specified in some way. The Root Bridge Driver category is also intersting (under "UEFI Driver Categories"); the core PciHostBridgeDxe in edk2 is a DXE_DRIVER. (It does have an elaborate depex though, and not just on architectural protocols.) Thanks! Laszlo >> -----Original Message----- >> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Laszlo Ersek >> Sent: Wednesday, October 5, 2016 2:18 PM >> To: Andrew Fish ; Daniil Egranov >> Cc: Carsey, Jaben ; edk2-devel-01 ; >> Leif Lindholm >> Subject: Re: [edk2] Assert in ShellPkg with latest tianocore edk2 source on the >> Reference Platform >> >> On 10/05/16 23:05, Andrew Fish wrote: >> >>> I'm guessing that your DXE Driver is dispatching prior UEFI Driver that publishes the >> protocol. >> >> BTW... Why is EnglishDxe a UEFI_DRIVER rather than a DXE_DRIVER? It >> doesn't conform to the UEFI driver model. (I'm not saying it *must* not >> be a UEFI_DRIVER, but what reason does it have for being one?) It also >> calls no runtime services, and only the >> InstallMultipleProtocolInterfaces() boot service; so I don't think it >> relies on all of the architectural protocols either. >> >> Thanks >> Laszlo >> >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel