From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Cc: EDK2 devel <edk2-devel@lists.sourceforge.net>,
Xen Devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH RFC 02/18] OvmfPkg: Add basic skeleton for the Xenbus driver.
Date: Wed, 16 Jul 2014 13:25:03 -0400 [thread overview]
Message-ID: <20140716172503.GC30483@laptop.dumpdata.com> (raw)
In-Reply-To: <1405523747-5024-3-git-send-email-anthony.perard@citrix.com>
On Wed, Jul 16, 2014 at 04:15:31PM +0100, Anthony PERARD wrote:
> This includes Component Name and Driver Binding.
The title says driver, but the cover letter said 'bus driver'.
Should it have bus driver in it?
.. snip..
> +/**
> + Retrieves a Unicode string that is the user readable name of the controller
> + that is being managed by an EFI Driver.
> +
> + @param This A pointer to the EFI_COMPONENT_NAME_PROTOCOL instance.
> + @param ControllerHandle The handle of a controller that the driver specified by
> + This is managing. This handle specifies the controller
> + whose name is to be returned.
> + @param ChildHandle The handle of the child controller to retrieve the name
> + of. This is an optional parameter that may be NULL. It
> + will be NULL for device drivers. It will also be NULL
> + for a bus drivers that wish to retrieve the name of the
> + bus controller. It will not be NULL for a bus driver
> + that wishes to retrieve the name of a child controller.
.. snip..
> +EFI_STATUS
> +EFIAPI
> +XenbusDxeComponentNameGetControllerName (
> + IN EFI_COMPONENT_NAME2_PROTOCOL *This,
> + IN EFI_HANDLE ControllerHandle,
> + IN EFI_HANDLE ChildHandle OPTIONAL,
> + IN CHAR8 *Language,
> + OUT CHAR16 **ControllerName
> + )
> +{
> + EFI_STATUS Status;
> +
> + //
> + // ChildHandle must be NULL for a Device Driver
OK, but this is a bus driver in which case ChildHandle can be NULL or not (at
least that is what the comment says) ?
> + //
> + if (ChildHandle != NULL) {
> + return EFI_UNSUPPORTED;
> + }
> +
> + //
> + // Lookup name of controller specified by ControllerHandle
> + //
> + Status = EFI_UNSUPPORTED;
> +
> + return Status;
> +}
.. snip..
> diff --git a/OvmfPkg/XenbusDxe/XenbusDxe.c b/OvmfPkg/XenbusDxe/XenbusDxe.c
> new file mode 100644
> index 0000000..14113ad
> --- /dev/null
> +++ b/OvmfPkg/XenbusDxe/XenbusDxe.c
> @@ -0,0 +1,314 @@
> +
> +/** @file
> + TODO: Brief Description of UEFI Driver XenbusDxe
> +
> + TODO: Detailed Description of UEFI Driver XenbusDxe
> +
> + TODO: Copyright for UEFI Driver XenbusDxe
> +
> + TODO: License for UEFI Driver XenbusDxe
> +
> +**/
> +
> +#include <IndustryStandard/Pci.h>
> +#include <IndustryStandard/Acpi.h>
> +#include <Library/DebugLib.h>
> +
> +#include "XenbusDxe.h"
> +
> +
> +///
> +/// Driver Binding Protocol instance
> +///
> +EFI_DRIVER_BINDING_PROTOCOL gXenbusDxeDriverBinding = {
> + XenbusDxeDriverBindingSupported,
> + XenbusDxeDriverBindingStart,
> + XenbusDxeDriverBindingStop,
> + XENBUS_DXE_VERSION,
> + NULL,
> + NULL
> +};
> +
> +
> +/**
> + Unloads an image.
> +
> + @param ImageHandle Handle that identifies the image to be unloaded.
> +
> + @retval EFI_SUCCESS The image has been unloaded.
> + @retval EFI_INVALID_PARAMETER ImageHandle is not a valid image handle.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +XenbusDxeUnload (
> + IN EFI_HANDLE ImageHandle
> + )
> +{
> + EFI_STATUS Status;
> +
> + EFI_HANDLE *HandleBuffer;
> + UINTN HandleCount;
> + UINTN Index;
> +
> +
> + Status = EFI_SUCCESS;
Is that neccessary considering the next line you overwrite it?
> +
> + //
> + // Retrieve array of all handles in the handle database
> + //
> + Status = gBS->LocateHandleBuffer (
> + AllHandles,
> + NULL,
> + NULL,
> + &HandleCount,
> + &HandleBuffer
> + );
> + if (EFI_ERROR (Status)) {
> + return Status;
> + }
> +
> + //
> + // Disconnect the current driver from handles in the handle database
> + //
> + for (Index = 0; Index < HandleCount; Index++) {
> + Status = gBS->DisconnectController (HandleBuffer[Index], gImageHandle, NULL);
> + }
Should you check the Status?
I guess it doesn't matter at all. In which case why don't you just
(void)gBS->DisconnectController ..
> +
> + //
> + // Free the array of handles
> + //
> + FreePool (HandleBuffer);
> +
> +
> + //
> + // Uninstall protocols installed in the driver entry point
> + //
> + Status = gBS->UninstallMultipleProtocolInterfaces (
> + ImageHandle,
> + &gEfiDriverBindingProtocolGuid, &gXenbusDxeDriverBinding,
> + &gEfiComponentNameProtocolGuid, &gXenbusDxeComponentName,
> + &gEfiComponentName2ProtocolGuid, &gXenbusDxeComponentName2,
> + NULL
> + );
> + if (EFI_ERROR (Status)) {
> + return Status;
> + }
> +
> +
> + //
> + // Do any additional cleanup that is required for this driver
> + //
> +
> + return EFI_SUCCESS;
> +}
> +
> +/**
> + This is the declaration of an EFI image entry point. This entry point is
> + the same for UEFI Applications, UEFI OS Loaders, and UEFI Drivers including
> + both device drivers and bus drivers.
> +
> + @param ImageHandle The firmware allocated handle for the UEFI image.
> + @param SystemTable A pointer to the EFI System Table.
> +
> + @retval EFI_SUCCESS The operation completed successfully.
> + @retval Others An unexpected error occurred.
> +**/
> +EFI_STATUS
> +EFIAPI
> +XenbusDxeDriverEntryPoint (
> + IN EFI_HANDLE ImageHandle,
> + IN EFI_SYSTEM_TABLE *SystemTable
> + )
> +{
> + EFI_STATUS Status;
> +
> +
> + Status = EFI_SUCCESS;
Not needed.
> +
> +
> + //
> + // Install UEFI Driver Model protocol(s).
> + //
> + Status = EfiLibInstallDriverBindingComponentName2 (
> + ImageHandle,
> + SystemTable,
> + &gXenbusDxeDriverBinding,
> + ImageHandle,
> + &gXenbusDxeComponentName,
> + &gXenbusDxeComponentName2
> + );
> + ASSERT_EFI_ERROR (Status);
> +
> +
> + return Status;
> +}
next prev parent reply other threads:[~2014-07-16 17:25 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1405523747-5024-1-git-send-email-anthony.perard@citrix.com>
2014-07-16 15:15 ` [PATCH RFC 01/18] OvmfPkg: Add public headers from Xen Project Anthony PERARD
2014-07-16 15:15 ` [PATCH RFC 02/18] OvmfPkg: Add basic skeleton for the Xenbus driver Anthony PERARD
2014-07-16 15:15 ` [PATCH RFC 03/18] OvmfPkg/XenbusDxe: Add device state struct and create an ExitBoot services event Anthony PERARD
2014-07-16 15:15 ` [PATCH RFC 04/18] OvmfPkg/XenbusDxe: Add support to make Xen Hypercalls Anthony PERARD
2014-07-16 15:15 ` [PATCH RFC 05/18] OvmfPkg/XenbusDxe: Open PciIo protocol Anthony PERARD
2014-07-16 15:15 ` [PATCH RFC 06/18] OvmfPkg: Introduce Xenbus Protocol Anthony PERARD
2014-07-16 15:15 ` [PATCH RFC 07/18] OvmfPkg/XenbusDxe: Add InterlockedCompareExchange16 Anthony PERARD
2014-07-16 15:15 ` [PATCH RFC 08/18] OvmfPkg/XenbusDxe: Add Grant Table functions Anthony PERARD
2014-07-16 15:15 ` [PATCH RFC 09/18] OvmfPkg/XenbusDxe: Add Event Channel Notify Anthony PERARD
2014-07-16 15:15 ` [PATCH RFC 10/18] OvmfPkg/XenbusDxe: Add TestAndClearBit Anthony PERARD
2014-07-16 15:15 ` [PATCH RFC 11/18] OvmfPkg/XenbusDxe: Add XenStore client implementation Anthony PERARD
2014-07-16 15:15 ` [PATCH RFC 12/18] OvmfPkg/XenbusDxe: Add an helper AsciiStrDup Anthony PERARD
2014-07-16 15:15 ` [PATCH RFC 13/18] OvmfPkg/XenbusDxe: Add Xenstore function into the Xenbus protocol Anthony PERARD
2014-07-16 15:15 ` [PATCH RFC 14/18] OvmfPkg/XenbusDxe: Indroduce XenBus support itself Anthony PERARD
2014-07-16 15:15 ` [PATCH RFC 15/18] OvmfPkg/XenbusDxe: Add Event Channel into XenBus protocol Anthony PERARD
2014-07-16 15:15 ` [PATCH RFC 16/18] OvmfPkg/XenPvBlkDxe: Xen PV Block device, initial skeleton Anthony PERARD
2014-07-16 15:15 ` [PATCH RFC 17/18] OvmfPkg/XenPvBlkDxe: Add BlockFront client Anthony PERARD
2014-07-16 15:15 ` [PATCH RFC 18/18] OvmfPkg/XenPvBlkDxe: Add BlockIo Anthony PERARD
[not found] ` <1405523747-5024-3-git-send-email-anthony.perard@citrix.com>
2014-07-16 17:25 ` Konrad Rzeszutek Wilk [this message]
2014-07-18 10:30 ` [PATCH RFC 02/18] OvmfPkg: Add basic skeleton for the Xenbus driver Anthony PERARD
[not found] ` <1405523747-5024-4-git-send-email-anthony.perard@citrix.com>
2014-07-16 17:32 ` [PATCH RFC 03/18] OvmfPkg/XenbusDxe: Add device state struct and create an ExitBoot services event Konrad Rzeszutek Wilk
2014-07-18 10:32 ` Anthony PERARD
[not found] ` <1405523747-5024-5-git-send-email-anthony.perard@citrix.com>
2014-07-16 17:37 ` [PATCH RFC 04/18] OvmfPkg/XenbusDxe: Add support to make Xen Hypercalls Konrad Rzeszutek Wilk
2014-07-17 9:43 ` Wei Liu
[not found] ` <1405523747-5024-6-git-send-email-anthony.perard@citrix.com>
2014-07-16 17:39 ` [PATCH RFC 05/18] OvmfPkg/XenbusDxe: Open PciIo protocol Konrad Rzeszutek Wilk
2014-07-18 10:36 ` Anthony PERARD
[not found] ` <1405523747-5024-7-git-send-email-anthony.perard@citrix.com>
2014-07-16 17:42 ` [PATCH RFC 06/18] OvmfPkg: Introduce Xenbus Protocol Konrad Rzeszutek Wilk
2014-07-18 10:40 ` Anthony PERARD
[not found] ` <1405523747-5024-9-git-send-email-anthony.perard@citrix.com>
2014-07-16 17:48 ` [PATCH RFC 08/18] OvmfPkg/XenbusDxe: Add Grant Table functions Konrad Rzeszutek Wilk
2014-07-18 10:53 ` Anthony PERARD
[not found] ` <1405523747-5024-15-git-send-email-anthony.perard@citrix.com>
2014-07-16 19:04 ` [PATCH RFC 14/18] OvmfPkg/XenbusDxe: Indroduce XenBus support itself Konrad Rzeszutek Wilk
2014-07-18 11:04 ` Anthony PERARD
[not found] ` <1405523747-5024-18-git-send-email-anthony.perard@citrix.com>
2014-07-16 19:41 ` [PATCH RFC 17/18] OvmfPkg/XenPvBlkDxe: Add BlockFront client Konrad Rzeszutek Wilk
2014-07-18 11:58 ` Anthony PERARD
[not found] ` <20140718115817.GG1582@perard.uk.xensource.com>
2014-07-18 18:36 ` Konrad Rzeszutek Wilk
[not found] ` <1405523747-5024-19-git-send-email-anthony.perard@citrix.com>
2014-07-16 19:57 ` [PATCH RFC 18/18] OvmfPkg/XenPvBlkDxe: Add BlockIo Konrad Rzeszutek Wilk
2014-07-18 12:10 ` Anthony PERARD
2014-07-16 20:10 ` [PATCH RFC 00/18] Introducing Xen PV block driver to OVMF Konrad Rzeszutek Wilk
2014-07-18 12:12 ` Anthony PERARD
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140716172503.GC30483@laptop.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=anthony.perard@citrix.com \
--cc=edk2-devel@lists.sourceforge.net \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).