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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.