Thanks to you all. Too much documentation, too little time always leads to
brain gas. Poor documentation
does not help. The example I referenced is very misleading as are many
others, not helpful for those of us
getting started - especially when the example is weird but plausibly
correct. Munging through source code
does get the right answer but is very time consuming and annoys the boss.
Plamen, your edit of my restaurant analogy is exactly what I was thinking.
I was trying to convey exactly
the confusion I had resultant from misleading documentation. Thanks much
for confirming that I am only
totally nuts...Computer 101 is still alive and well!
So my picture is this. If I have a piece of hardware that has, for example,
a block I/O device and a mouse,
then the driver I would write would implement and produce block I/O
protocol and simple pointer protocol
(plus any other needed protocols that are not implemented in firmware). The
protocols are merely standardized
APIs for device classes and services. The driver then, as a set of
protocols, is assigned a handle in the
firmware, the driver does not care about handles as they implement a higher
level of abstraction. Conversely,
as an application, if I need, say, a pointing device then I simply look for
the existence of a simple pointer
protocol, and if it exists a pointing device is attached to the platform
and the handle/protocol provide the
reference to access the device. UEFI is the music, EDK are the instruments
that play the tune. If I am wrong
here, please don't hesitate to chastise me without mercy...<G>
Again, thanks much!!!
On Thu, Oct 11, 2012 at 9:50 AM, Belomorski, Plamen <
plamen.belomor...@amd.com> wrote:
> Duck, your example may need a little adjustment. If you have a restaurant,
> some agency will assign for you a dishwasher. You don't really care if this
> guy is washing dishes everywhere or works only for you (both types exist).
> All you need is to get a pointer to that guy so you can give him your
> orders in his language. LocateHandleBuffer will give you list of all
> dishwashers, you have to tell which one is yours.
> Thanks,
> P
>
> -----Original Message-----
> From: Sergey Isakov [mailto:isakov...@bk.ru]
> Sent: Thursday, October 11, 2012 1:53 AM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] Protocol Questions
>
> Hi,
> You should attach the protocol to the device handle.
>
> On 11.10.2012, at 9:26, duck wilson wrote:
>
> > Greetings,
> >
> > I have managed to get wrapped around my axle in understanding the
> implementation
> > and use of protocols in UEFI. I "think" the working model I have is
> correct
> > but am not sure at this point, help would be much appreciated. To
> illustrate my
> > confusion, refer to the source code below taken from the "Driver Writer's
> > Guide for UEFI 2.3.1", Version 1.01, 3/08/2012, Section 5.1.3.2, Example
> 36
> > on pages 116-117. The example shows how to retrieve all Block I/O
> Protocols
> > from the handle database using LocateHandleBuffer and OpenProtocol. In
> the
> > loop where the OpenProtocol call is made, the interface pointer is
> written
> > to the same variable, BlockIo, for each handle which I am interpreting to
> > mean that all handles use one, and only one, instance in the system that
> > implements BLOCK_IO_PROTOCOL and so one interface instance, that is,
> there is
> > a one-to-many mapping. There are similar examples in the UEFI
> specification.
> > I further interpret this to mean that if I am writing a driver for a
> device
> > that needs BLOCK_IO_PROTOCOL services that I simply use the existing
> protocol
> > and do not have to write an implementation for this service. Is this
> correct?
> >
> > Also, when using a protocol, is it necessary to open all handle instances
> > of a protocol when using a protocol as the examples shows in either a
> > driver or application? For example, if I am using a device on a device
> path,
> > which is a protocol mapped to a handle, do I also need to open all other
> > instances on all other handles to use the device or just open the handle
> > needed?
> >
> > To make my confusion more concrete let's move the model outside the
> realm of
> > computers. Assume that a protocol is a dishwasher, that a handle is a
> restaurant,
> > and that hiring the dishwasher is the equivalent of opening a protocol.
> The
> > dishwasher's name happens to be GUID. Are all restaurants required to
> have
> > dishwashers named GUID, in which case there are a lot of persons named
> GUID
> > who are dishwashers, or is there just one dishwasher named GUID who
> provides
> > dish washing services to all the restaurants? In either case, the
> pairing of
> > a restaurant with GUID is unique, however, in the former case there are
> many
> > different people with the same name doing the same work and in the later
> case
> > just on person doing all the work. So if I go into the restaurant
> business, do I
> > need to find another dishwasher named GUID or do I need to contract with
> the
> > one dishwasher named GUID? What is the correct model?
> >
> > TIA!
> >
> >
> > #include <Uefi.h>
> > #include <Library/UefiBootServicesTableLib.h>
> > #include <Library/MemoryAllocationLib.h>
> > #include <Protocol/BlockIo.h>
> >
> > EFI_STATUS Status;
> > UINTN HandleCount;
> > EFI_HANDLE *HandleBuffer;
> > UINTN Index;
> > EFI_BLOCK_IO_PROTOCOL *BlockIo;
> >
> > //
> > // Retrieve the list of handles that support the Block I/O
> > // Protocol from the handle database. The number of handles
> > // that support the Block I/O Protocol is returned in HandleCount,
> > // and the array of handle values is returned in HandleBuffer
> > // which is allocated using AlocatePool()
> > //
> >
> > Status = gBS->LocateHandleBuffer (
> > ByProtocol,
> > &gEfiBlockIoProtocolGuid,
> > NULL,
> > &HandleCount,
> > &HandleBuffer
> > );
> > if (EFI_ERROR (Status)) {
> > return Status;
> > }
> >
> > //
> > // Loop through all the handles that support the Block I/O
> > // Protocol, and retrieve the Block I/O Protocol instance
> > // from each handle.
> > //
> >
> > for (Index = 0; Index < HandleCount; Index++) {
> > Status = gBS->OpenProtocol (
> > HandleBuffer[Index],
> > &gEfiBlockIoProtocolGuid,
> > (VOID **)&BlockIo,
> > gImageHandle,
> > NULL,
> > EFI_OPEN_PROTOCOL_GET_PROTOCOL
> > );
> > if (EFI_ERROR (Status)) {
> > return Status;
> > }
> >
> > //
> > // BlockIo can be used here to make Block I/O Protocol
> > // service requests.
> > //
> > }
> >
> > //
> > // Free the array of handles allocated by gBS->LocateHandleBuffer()
> > //
> > FreePool (HandleBuffer);
> >
> >
> ------------------------------------------------------------------------------
> > Don't let slow site performance ruin your business. Deploy New Relic APM
> > Deploy New Relic app performance management and know exactly
> > what is happening inside your Ruby, Python, PHP, Java, and .NET app
> > Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> >
> http://p.sf.net/sfu/newrelic-dev2dev_______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
