date:20140530

[edk2] How to add Unicode string in EDKII

2014-05-30 Thread cheney chen

Hi experts,
First of all, this is not a real use case so don't be surprised if it looks to 
be strange question.
I tried to print a simple Chinese string on screen, e.g. Chinese welcome string 
"欢迎您". Here is what I did (case is simplified wherever necessary).
CHAR16 WelcomeStr[4];...WelcomeStr[0] = 0x6B22;WelcomeStr[1] = 
0x8FCE;WelcomeStr[2] = 0x60A8;WelcomeStr[3] = 
L'\0';...gST->ConOut->OutputString(gST->ConOut, WelcomeStr);...
Is it a right way? And how/where to add these Unicode characters to firmware 
image?
By the way, any doc to describe multi-language support in EDKII?
Thanks,Cheney --
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] ReinstallProtocolInterface to notify filesystem driver?

2014-05-30 Thread Felipe Mesquita

Hi everyone,

Thank you all for the answers - and I'm glad that this question at least
was useful to fix a typo in the specs :)

So if I understood it right, ReinstallProtocolInterface() is working in
this case because:

 1) It's calling ConnectController() under the hoods...
 2) ...which triggers the FAT driver's (that follows the Uefi Driver Model)
Supported() and Start() functions...
 3) ...which eventually receive the RAM disk handle as argument and finally
creates the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL for it.

Is that correct?

Att,


On Thu, May 29, 2014 at 4:26 PM, Andrew Fish  wrote:

>
> On May 29, 2014, at 11:57 AM, Laszlo Ersek  wrote:
>
> > On 05/29/14 17:22, Andrew Fish wrote:
> >
> >> Because this is obsolete EFI 1.0 behavior. Per UEFI 2.4
> >> ReinstallProtocolInterface()
> >
> > Ah, thanks for the reference, I wasn't aware that an internal
> > uninstall/install/connect triple was performed.
> >
> > However, I think we may have found a confusing typo here (your quote is
> > faithful and the spec needs the update):
> >
>
> I filed a bug against the spec.
>
> Thanks,
>
> Andrew Fish
>
> >>
> >> EFI 1.10 Extension
> >> The extension to this service directly addresses the limitations
> >> described in the section above. There may be some number of drivers
> >> currently consuming the protocol interface that is being reinstalled. In
> >> this case, it may be dangerous to replace a protocol interface in the
> >> system. It could result in an unstable state, because a driver may
> >> attempt to use the old protocol interface after a new one has
> >> been reinstalled. Since the usage of protocol interfaces is now being
> >> tracked for components that use the OpenProtocol() and CloseProtocol()
> >> boot services, a safe version of this function can be implemented.
> >
> > ... OK thus far...
> >
> >> When this function is called, a call is first made to the boot service
> >> InstallProtocolInterface().
> >
> > Right here -- I think the first call must be to
> > *Un*installProtocolInterface(). That would be consistent with:
> >
> >> This will guarantee that all of the agents [that] are currently
> >> consuming the protocol interface OldInterface will stop using
> OldInterface.
> >
> > Thanks,
> > Laszlo
> >
> >
> --
> > Time is money. Stop wasting it! Get your web API in 5 minutes.
> > www.restlet.com/download
> > http://p.sf.net/sfu/restlet
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
> --
> Time is money. Stop wasting it! Get your web API in 5 minutes.
> www.restlet.com/download
> http://p.sf.net/sfu/restlet
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>



-- 
[image: LSBD] 
*Felipe Martins Mesquita*

Technical Lead

BSc in Computer Science - UFC

GTalk: felipe.mesqu...@lsbd.ufc.br

Skype: felipe.martins23
--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Minnowboard and UDK debugger 1.4.

2014-05-30 Thread Ricardo Menzer

Hi!
I'm using the Shell Bay development board (which is based on the Atom
e6xx + EG20T) and I'm also having difficulties to connect to the
debugger.
When I try to connect the UDK Debugger to the target system, it says
the debug agent version should be, at least, version 0.85.
I'm using the Intel BLDK to generate the firmware. Agent's version is
0.70. I tried to overwrite the SourceLevelDebugPkg with a newer
version downloaded from tianocore website but couldn't build a image
with this new one.

My question is: how to update the Debug Agent on target, or where do I
find a version of the Debug Tool that is compatible with version 0.70
of the target agent?

Thank you!

On Mon, May 26, 2014 at 6:46 PM,   wrote:
> That would be minnowboard. Changing the title.
>
> Sent from my BlackBerry Q10 smartphone.
> From: plarus...@gmail.com
> Sent: Monday, May 26, 2014 2:44 PM
> To: edk2-devel@lists.sourceforge.net
> Subject: Minboardnow and UDK debugger 1.4.
>
>
> Is anyone using the UDK debugger with the minboardnow (the $190 model)? The
> debugger does not connect the target for me. The target version is 1.3.1, as
> found in the provided uefi debug image (kit 1.0).
>
> Also, is there a way to obtain the entire uefi source code? Quite a few
> modules are only provided in binary form.
>
> Sent from my BlackBerry Q10 smartphone.
>
>
> --
> The best possible search technologies are now affordable for all companies.
> Download your FREE open source Enterprise Search Engine today!
> Our experts will assist you in its installation for $59/mo, no commitment.
> Test it for FREE on our Cloud platform anytime!
> http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>

-- 
---
Ricardo Menzer
ricardomen...@gmail.com
http://www.students.ic.unicamp.br/~ra092856/index.php
(32)8865-8805

--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] UEFI Development Board

2014-05-30 Thread Ludovic Rousseau

2014-05-26 18:54 GMT+02:00 André Dantas :

> Hello Everyone.
>

Hello,

Do you recommend any board that supports UEFI development? I saw in the
> Intel's website two options, but the shipping is limited to USA. Do you
> have any suggestions( with shipment to Brazil )?
>

Can you give me the URLs of the 2 Intel options you mention?

Thanks

-- 
 Dr. Ludovic Rousseau
--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH] edksetup: Fix EDK_TOOLS_PATH misbehaving

2014-05-30 Thread Paulo Alcantara

From: Victor Gouveia 

EDK_TOOLS_PATH is not updated correctly when calling edksetup.bat in
different workspaces, since if EDK_TOOLS_PATH is initially set to
C:\a\BaseTools and then call edksetup.bat again in another workspace
(e.g. C:\b\), the EDK_TOOLS_PATH will remain unchanged have the old path
set (C:\a\BaseTools).

This patch fixes the incorrect setting of EDK_TOOLS_PATH environment
variable.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Victor Gouveia 
---
 edksetup.bat | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/edksetup.bat b/edksetup.bat
index ba775ce..0304441 100755
--- a/edksetup.bat
+++ b/edksetup.bat
@@ -89,7 +89,7 @@ shift
 
 :no_nt32
 if /I "%1"=="NewBuild" shift
-if not defined EDK_TOOLS_PATH set EDK_TOOLS_PATH=%WORKSPACE%\BaseTools
+set EDK_TOOLS_PATH=%WORKSPACE%\BaseTools
 IF NOT EXIST "%EDK_TOOLS_PATH%\toolsetup.bat" goto BadBaseTools
 call %EDK_TOOLS_PATH%\toolsetup.bat %*
 if /I "%1"=="Reconfig" shift
-- 
1.9.2.msysgit.0


--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] How to add Unicode string in EDKII

2014-05-30 Thread Andrew Fish

On May 30, 2014, at 1:29 AM, cheney chen  wrote:

> Hi experts,
> 
> First of all, this is not a real use case so don't be surprised if it looks 
> to be strange question.
> 
> I tried to print a simple Chinese string on screen, e.g. Chinese welcome 
> string "欢迎您". Here is what I did (case is simplified wherever necessary).
> 
> CHAR16 WelcomeStr[4];
> ...
> WelcomeStr[0] = 0x6B22;
> WelcomeStr[1] = 0x8FCE;
> WelcomeStr[2] = 0x60A8;
> WelcomeStr[3] = L'\0';
> ...
> gST->ConOut->OutputString(gST->ConOut, WelcomeStr);
> ...
> 
> Is it a right way? And how/where to add these Unicode characters to firmware 
> image?
> 

You use the Hii protocol to add fonts. 

Take a look at the RegisterFontPackage() function in 
https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsole.c

The Graphics Console driver carries the basic Roman fonts. This is the only 
font available in the edk2 that I know about. But the infrastructure supports 
adding more fonts. 

> By the way, any doc to describe multi-language support in EDKII?
> 

Not sure about a doc? Localization is done via *.uni files. Here is an example 
one from the shell 
https://svn.code.sf.net/p/edk2/code/trunk/edk2/ShellPkg/Application/Shell/Shell.uni,
 you can have multiple languages per token. The default EFI language is used. 
The Shell uses the STRING_TOKEN() macro to access the string, and this is all 
taken care of via the build system. For the most part the shell uses the 
ShellPrintHiiEx(), so you can look that that to understand what Hii things are 
going on.

How Hii works is documented in the UEFI spec, and I assume one of the build 
specs talks about UNI files. 

If you have a terminal connection that supports UTF-8 it would Just Work(tm), 
assuming the terminal emulation program supported the font. 

Thanks,

Andrew Fish

> Thanks,
> Cheney
> --
> Time is money. Stop wasting it! Get your web API in 5 minutes.
> www.restlet.com/download
> http://p.sf.net/sfu/restlet___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] ReinstallProtocolInterface to notify filesystem driver?

2014-05-30 Thread Laszlo Ersek

On 05/30/14 13:43, Felipe Mesquita wrote:
> Hi everyone,
> 
> Thank you all for the answers - and I'm glad that this question at least
> was useful to fix a typo in the specs :)
> 
> So if I understood it right, ReinstallProtocolInterface() is working in
> this case because:
> 
>  1) It's calling ConnectController() under the hoods...
>  2) ...which triggers the FAT driver's (that follows the Uefi Driver
> Model) Supported() and Start() functions...
>  3) ...which eventually receive the RAM disk handle as argument and
> finally creates the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL for it.
> 
> Is that correct?

I think so.
Laszlo


--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] ReinstallProtocolInterface to notify filesystem driver?

2014-05-30 Thread Andrew Fish


On May 30, 2014, at 4:43 AM, Felipe Mesquita  
wrote:

> Hi everyone,
> 
> Thank you all for the answers - and I'm glad that this question at least was 
> useful to fix a typo in the specs :)
> 
> So if I understood it right, ReinstallProtocolInterface() is working in this 
> case because:
> 
>  1) It's calling ConnectController() under the hoods…
1.9) Disk IO protocol layers on the handle too. 
>  2) ...which triggers the FAT driver's (that follows the Uefi Driver Model) 
> Supported() and Start() functions...
>  3) ...which eventually receive the RAM disk handle as argument and finally 
> creates the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL for it.
> 

The FAT Driver’s Start() function is passed the ControllerHandle for the 
BlockIo/DiskIo handle. It will read blocks from the disk to see if it can find 
a valid file system. 

> Is that correct?
> 

Yes. Also EFI_SIMPLE_FILE_SYSTEM_PROTOCOL is not FAT32 specific, it can be used 
to abstract any file system type. So the RAM disk driver could have just 
produced EFI_SIMPLE_FILE_SYSTEM_PROTOCOL and the files would have been stored 
in a malloced linked list. 

Thanks,

Andrew Fish

> Att,
> 
> 
> On Thu, May 29, 2014 at 4:26 PM, Andrew Fish  wrote:
> 
> On May 29, 2014, at 11:57 AM, Laszlo Ersek  wrote:
> 
> > On 05/29/14 17:22, Andrew Fish wrote:
> >
> >> Because this is obsolete EFI 1.0 behavior. Per UEFI 2.4
> >> ReinstallProtocolInterface()
> >
> > Ah, thanks for the reference, I wasn't aware that an internal
> > uninstall/install/connect triple was performed.
> >
> > However, I think we may have found a confusing typo here (your quote is
> > faithful and the spec needs the update):
> >
> 
> I filed a bug against the spec.
> 
> Thanks,
> 
> Andrew Fish
> 
> >>
> >> EFI 1.10 Extension
> >> The extension to this service directly addresses the limitations
> >> described in the section above. There may be some number of drivers
> >> currently consuming the protocol interface that is being reinstalled. In
> >> this case, it may be dangerous to replace a protocol interface in the
> >> system. It could result in an unstable state, because a driver may
> >> attempt to use the old protocol interface after a new one has
> >> been reinstalled. Since the usage of protocol interfaces is now being
> >> tracked for components that use the OpenProtocol() and CloseProtocol()
> >> boot services, a safe version of this function can be implemented.
> >
> > ... OK thus far...
> >
> >> When this function is called, a call is first made to the boot service
> >> InstallProtocolInterface().
> >
> > Right here -- I think the first call must be to
> > *Un*installProtocolInterface(). That would be consistent with:
> >
> >> This will guarantee that all of the agents [that] are currently
> >> consuming the protocol interface OldInterface will stop using OldInterface.
> >
> > Thanks,
> > Laszlo
> >
> > --
> > Time is money. Stop wasting it! Get your web API in 5 minutes.
> > www.restlet.com/download
> > http://p.sf.net/sfu/restlet
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/edk2-devel
> 
> 
> --
> Time is money. Stop wasting it! Get your web API in 5 minutes.
> www.restlet.com/download
> http://p.sf.net/sfu/restlet
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
> 
> 
> 
> -- 
> 
> Felipe Martins Mesquita
> Technical Lead
> BSc in Computer Science - UFC
> GTalk: felipe.mesqu...@lsbd.ufc.br
> Skype: felipe.martins23
> --
> Time is money. Stop wasting it! Get your web API in 5 minutes.
> www.restlet.com/download
> http://p.sf.net/sfu/restlet___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] Signalling an event group

2014-05-30 Thread Justin_Johnson1

Hello all,
I'm working with the DXE core event services and am not sure that the code in 
MdeModulePkg agrees with the UEFI spec.
The situation is this: in several modules I have created an event using the 
CreateEventEx() method, with an EventGroup GUID. Later, I want to signal the 
event group, but the module which does the signaling does not have any work to 
do in response to the event. It would seem that I can signal the event by doing 
as indicated in the UEFI spec:
gBS->CreateEventEx (
  0,
  0,
  NULL,
  NULL,
  &gMyEventGroupGuid,
  &Event);
gBS->SignalEvent(Event);

However, this does not work with EDKII. I see in Event.c :
if ((Event->Type & EVT_NOTIFY_SIGNAL) != 0) {
  if (Event->ExFlag) {
//
// The CreateEventEx() style requires all members of the Event Group
//  to be signaled.
//
CoreReleaseEventLock ();
CoreNotifySignalList (&Event->EventGroup);
CoreAcquireEventLock ();

Which seems to indicate that the event group is only signaled if the event 
being signaled is of type EVT_NOTIFY_SIGNAL. In order to get my event group 
signaled, I must create an event with a dummy callback and give it type 
EVT_NOTIFY_SIGNAL, even though I do not have any work to do in response to the 
event.

Is this an error in MdeModulePkg's implementation? Or is the spec incomplete?

Thanks.

--
Justin Johnson
Platform Software Engineer
Dell, Inc.

--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Signalling an event group

2014-05-30 Thread Andrew Fish

Justin,

This looks like a bug in the DXE Core. 

As you point out the example in the UEFI spec on how to signal the event does 
not work in the edk2. I do not see a hard requirement that all events in an 
event group need to have a notification function. The spec seems to say the 
opposite, that all the notification functions associated with the event will be 
signaled by the DXE Core. 

UEFI 2.4 SignalEvent() Description

ThesuppliedEventisplacedinthesignaledstate. 
IfEventisalreadyinthesignaledstate,then EFI_SUCCESS is returned. If Event is of 
type EVT_NOTIFY_SIGNAL, then the event’s notification function is scheduled to 
be invoked at the event’s notification task priority level. SignalEvent() may 
be invoked from any task priority level.

If the supplied Event is a part of an event group, then all of the events in 
the event group are also signaled and their notification functions are 
scheduled.

When signaling an event group, it is possible to create an event in the group, 
signal it and then close the event to remove it from the group. For example:
   EFI_EVENT Event;
   EFI_GUID gMyEventGroupGuid = EFI_MY_EVENT_GROUP_GUID;
   gBS->CreateEventEx (
 0,
 0,
 NULL,
 NULL,
 &gMyEventGroupGuid,
 &Event
   );
   gBS->SignalEvent (Event);
   gBS->CloseEvent (Event);

Thanks,

Andrew Fish

PS I hit this a few days ago and ended up adding the dummy callback event to 
make it work. I guess I should have double checked the spec! 

On May 30, 2014, at 11:00 AM, justin_johns...@dell.com wrote:

> Hello all,
> I’m working with the DXE core event services and am not sure that the code in 
> MdeModulePkg agrees with the UEFI spec.
> The situation is this: in several modules I have created an event using the 
> CreateEventEx() method, with an EventGroup GUID. Later, I want to signal the 
> event group, but the module which does the signaling does not have any work 
> to do in response to the event. It would seem that I can signal the event by 
> doing as indicated in the UEFI spec:
> gBS->CreateEventEx (
>   0,
>   0,
>   NULL,
>   NULL,
>   &gMyEventGroupGuid,
>   &Event);
> gBS->SignalEvent(Event);
>  
> However, this does not work with EDKII. I see in Event.c :
> if ((Event->Type & EVT_NOTIFY_SIGNAL) != 0) {
>   if (Event->ExFlag) {
> //
> // The CreateEventEx() style requires all members of the Event Group
> //  to be signaled.
> //
> CoreReleaseEventLock ();
> CoreNotifySignalList (&Event->EventGroup);
> CoreAcquireEventLock ();
>  
> Which seems to indicate that the event group is only signaled if the event 
> being signaled is of type EVT_NOTIFY_SIGNAL. In order to get my event group 
> signaled, I must create an event with a dummy callback and give it type 
> EVT_NOTIFY_SIGNAL, even though I do not have any work to do in response to 
> the event.
>  
> Is this an error in MdeModulePkg’s implementation? Or is the spec incomplete?
>  
> Thanks.
>  
> --
> Justin Johnson
> Platform Software Engineer
> Dell, Inc.
>  
> --
> Time is money. Stop wasting it! Get your web API in 5 minutes.
> www.restlet.com/download
> http://p.sf.net/sfu/restlet___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Signalling an event group

2014-05-30 Thread Andrew Fish


On May 30, 2014, at 11:51 AM, Andrew Fish  wrote:

> 
> On May 30, 2014, at 11:00 AM, justin_johns...@dell.com wrote:
> 
>> Hello all,
>> I’m working with the DXE core event services and am not sure that the code 
>> in MdeModulePkg agrees with the UEFI spec.
>> The situation is this: in several modules I have created an event using the 
>> CreateEventEx() method, with an EventGroup GUID. Later, I want to signal the 
>> event group, but the module which does the signaling does not have any work 
>> to do in response to the event. It would seem that I can signal the event by 
>> doing as indicated in the UEFI spec:
>> gBS->CreateEventEx (
>>   0,
>>   0,
>>   NULL,
>>   NULL,
>>   &gMyEventGroupGuid,
>>   &Event);
>> gBS->SignalEvent(Event);
>>  
>> However, this does not work with EDKII. I see in Event.c :
>> if ((Event->Type & EVT_NOTIFY_SIGNAL) != 0) {
>>   if (Event->ExFlag) {
>> //
>> // The CreateEventEx() style requires all members of the Event Group
>> //  to be signaled.
>> //
>> CoreReleaseEventLock ();
>> CoreNotifySignalList (&Event->EventGroup);
>> CoreAcquireEventLock ();
>>  
>> Which seems to indicate that the event group is only signaled if the event 
>> being signaled is of type EVT_NOTIFY_SIGNAL. In order to get my event group 
>> signaled, I must create an event with a dummy callback and give it type 
>> EVT_NOTIFY_SIGNAL, even though I do not have any work to do in response to 
>> the event.
>>  
>> Is this an error in MdeModulePkg’s implementation? Or is the spec incomplete?
>>  

Justin,

I think the logic in the DXE Core should look like this:

  if (Event->SignalCount == 0x) {
Event->SignalCount++;

if  (Event->ExFlag) {
//
// The CreateEventEx() style requires all members of the Event Group
//  to be signaled.
//
CoreReleaseEventLock ();
CoreNotifySignalList (&Event->EventGroup);
CoreAcquireEventLock ();
} else if ((Event->Type & EVT_NOTIFY_SIGNAL) != 0) {
//
// If signalling type is a notify function, queue it
//
CoreNotifyEvent (Event);
}
  }

So always walk the List for an Ex event, but only notify the event if it is the 
right type. And the check should be in CoreNotifySignalList()

VOID
CoreNotifySignalList (
  IN EFI_GUID *EventGroup
  )
{
  LIST_ENTRY  *Link;
  LIST_ENTRY  *Head;
  IEVENT  *Event;

  CoreAcquireEventLock ();

  Head = &gEventSignalQueue;
  for (Link = Head->ForwardLink; Link != Head; Link = Link->ForwardLink) {
Event = CR (Link, IEVENT, SignalLink, EVENT_SIGNATURE);
if (CompareGuid (&Event->EventGroup, EventGroup)) {
   if ((Event->Type & EVT_NOTIFY_SIGNAL) != 0) {
CoreNotifyEvent (Event);
  }
}
  }

  CoreReleaseEventLock ();
}


Man, this code has been busted for a long time…. This bug predates the edk2!

The edk2 UefiLib even has a Dummy event and tries to hide the need for it from 
the caller….

https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Library/UefiLib/UefiNotTiano.c
/**
  An empty function to pass error checking of CreateEventEx ().

  This empty function ensures that EVT_NOTIFY_SIGNAL_ALL is error
  checked correctly since it is now mapped into CreateEventEx() in UEFI 2.0.
 
  @param  Event Event whose notification function is being 
invoked.
  @param  Context   The pointer to the notification function's 
context,
which is implementation-dependent.

**/
VOID
EFIAPI
InternalEmptyFunction (
  IN EFI_EVENTEvent,
  IN VOID *Context
  )
{
  return;
}

EFI_STATUS
EFIAPI
EfiCreateEventReadyToBootEx (
  IN  EFI_TPL   NotifyTpl,
  IN  EFI_EVENT_NOTIFY  NotifyFunction,  OPTIONAL
  IN  VOID  *NotifyContext,  OPTIONAL
  OUT EFI_EVENT *ReadyToBootEvent
  )
{
  EFI_STATUSStatus;
  EFI_EVENT_NOTIFY  WorkerNotifyFunction;

  ASSERT (ReadyToBootEvent != NULL);

  if (gST->Hdr.Revision < EFI_2_00_SYSTEM_TABLE_REVISION) {
DEBUG ((EFI_D_ERROR, "EFI1.1 can't support ReadyToBootEvent!"));
ASSERT (FALSE);

return EFI_UNSUPPORTED;
  } else {
//
// For UEFI 2.0 and the future use an Event Group
//
if (NotifyFunction == NULL) {
  //
  // CreateEventEx will check NotifyFunction is NULL or not and return 
error.
  // Use dummy routine for the case NotifyFunction is NULL.
  //
  WorkerNotifyFunction = InternalEmptyFunction;
} else {
  WorkerNotifyFunction = NotifyFunction;
}
Status = gBS->CreateEventEx (
EVT_NOTIFY_SIGNAL,
NotifyTpl,
WorkerNotifyFunction,
NotifyContext,
&gEfiEventReadyToBootGuid,
ReadyToBootEvent
);
  }

  return Status;
}



Thanks,

Andrew Fish


>> Thanks.
>>  
>> --
>> Justin Jo

Re: [edk2] Signalling an event group

2014-05-30 Thread Justin_Johnson1

Andrew,
Your suggested code makes sense to me, I will give it a try. Besides that 
sample code snippet, I don't think the spec isn't really explicit; but does 
imply that the entire group is signaled, regardless of whether the event itself 
is of type EVT_NOTIFY_SIGNAL.

-- Justin



-Original Message-
From: Andrew Fish [mailto:af...@apple.com]
Sent: Friday, May 30, 2014 2:19 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Signalling an event group


On May 30, 2014, at 11:51 AM, Andrew Fish wrote:

>
> On May 30, 2014, at 11:00 AM, justin_johns...@dell.com wrote:
>
>> Hello all,
>> I'm working with the DXE core event services and am not sure that the code 
>> in MdeModulePkg agrees with the UEFI spec.
>> The situation is this: in several modules I have created an event using the 
>> CreateEventEx() method, with an EventGroup GUID. Later, I want to signal the 
>> event group, but the module which does the signaling does not have any work 
>> to do in response to the event. It would seem that I can signal the event by 
>> doing as indicated in the UEFI spec:
>> gBS->CreateEventEx (
>> 0,
>> 0,
>> NULL,
>> NULL,
>> &gMyEventGroupGuid,
>> &Event);
>> gBS->SignalEvent(Event);
>>
>> However, this does not work with EDKII. I see in Event.c :
>> if ((Event->Type & EVT_NOTIFY_SIGNAL) != 0) {
>> if (Event->ExFlag) {
>> //
>> // The CreateEventEx() style requires all members of the Event Group
>> // to be signaled.
>> //
>> CoreReleaseEventLock ();
>> CoreNotifySignalList (&Event->EventGroup);
>> CoreAcquireEventLock ();
>>
>> Which seems to indicate that the event group is only signaled if the event 
>> being signaled is of type EVT_NOTIFY_SIGNAL. In order to get my event group 
>> signaled, I must create an event with a dummy callback and give it type 
>> EVT_NOTIFY_SIGNAL, even though I do not have any work to do in response to 
>> the event.
>>
>> Is this an error in MdeModulePkg's implementation? Or is the spec incomplete?
>>

Justin,

I think the logic in the DXE Core should look like this:

if (Event->SignalCount == 0x) {
Event->SignalCount++;

if (Event->ExFlag) {
//
// The CreateEventEx() style requires all members of the Event Group
// to be signaled.
//
CoreReleaseEventLock ();
CoreNotifySignalList (&Event->EventGroup);
CoreAcquireEventLock ();
} else if ((Event->Type & EVT_NOTIFY_SIGNAL) != 0) {
//
// If signalling type is a notify function, queue it
//
CoreNotifyEvent (Event);
}
}

So always walk the List for an Ex event, but only notify the event if it is the 
right type. And the check should be in CoreNotifySignalList()

VOID
CoreNotifySignalList (
IN EFI_GUID *EventGroup
)
{
LIST_ENTRY *Link;
LIST_ENTRY *Head;
IEVENT *Event;

CoreAcquireEventLock ();

Head = &gEventSignalQueue;
for (Link = Head->ForwardLink; Link != Head; Link = Link->ForwardLink) {
Event = CR (Link, IEVENT, SignalLink, EVENT_SIGNATURE);
if (CompareGuid (&Event->EventGroup, EventGroup)) {
if ((Event->Type & EVT_NOTIFY_SIGNAL) != 0) {
CoreNotifyEvent (Event);
}
}
}

CoreReleaseEventLock ();
}


Man, this code has been busted for a long time This bug predates the edk2!

The edk2 UefiLib even has a Dummy event and tries to hide the need for it from 
the caller

https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Library/UefiLib/UefiNotTiano.c
/**
An empty function to pass error checking of CreateEventEx ().

This empty function ensures that EVT_NOTIFY_SIGNAL_ALL is error
checked correctly since it is now mapped into CreateEventEx() in UEFI 2.0.

@param Event Event whose notification function is being invoked.
@param Context The pointer to the notification function's context,
which is implementation-dependent.

**/
VOID
EFIAPI
InternalEmptyFunction (
IN EFI_EVENT Event,
IN VOID *Context
)
{
return;
}

EFI_STATUS
EFIAPI
EfiCreateEventReadyToBootEx (
IN EFI_TPL NotifyTpl,
IN EFI_EVENT_NOTIFY NotifyFunction, OPTIONAL
IN VOID *NotifyContext, OPTIONAL
OUT EFI_EVENT *ReadyToBootEvent
)
{
EFI_STATUS Status;
EFI_EVENT_NOTIFY WorkerNotifyFunction;

ASSERT (ReadyToBootEvent != NULL);

if (gST->Hdr.Revision < EFI_2_00_SYSTEM_TABLE_REVISION) {
DEBUG ((EFI_D_ERROR, "EFI1.1 can't support ReadyToBootEvent!"));
ASSERT (FALSE);

return EFI_UNSUPPORTED;
} else {
//
// For UEFI 2.0 and the future use an Event Group
//
if (NotifyFunction == NULL) {
//
// CreateEventEx will check NotifyFunction is NULL or not and return error.
// Use dummy routine for the case NotifyFunction is NULL.
//
WorkerNotifyFunction = InternalEmptyFunction;
} else {
WorkerNotifyFunction = NotifyFunction;
}
Status = gBS->CreateEventEx (
EVT_NOTIFY_SIGNAL,
NotifyTpl,
WorkerNotifyFunction,
NotifyContext,
&gEfiEventReadyToBootGuid,
ReadyToBootEvent
);
}

return Status;
}



Thanks,

Andrew Fish


>> Thanks.
>>
>> --
>> Justin Johnson
>> Platform Software Engineer
>> Dell, Inc.
>>
>> -
>> - Time is money. Stop wasting it! Get your web API in 5
>> minutes.
>> www.restlet.com/do

Re: [edk2] Signalling an event group

2014-05-30 Thread Andrew Fish


On May 30, 2014, at 12:41 PM, justin_johns...@dell.com wrote:

> Andrew,
> Your suggested code makes sense to me, I will give it a try. Besides that 
> sample code snippet, I don’t think the spec isn’t really explicit; but does 
> imply that the entire group is signaled, regardless of whether the event 
> itself is of type EVT_NOTIFY_SIGNAL.
>  

The reason CreateEventEx() got created was to allow the signaling of a group of 
functions so they could run their notify function. But the example clearly 
shows it is legal to create and Ex event of any type. The spec does say the 
event is signaled and their notification functions are schedule. 

Good point, if all the events got signaled I think CoreNotifySignalList() would 
look more like:

VOID
CoreNotifySignalList (
 IN EFI_GUID *EventGroup
 )
{
 LIST_ENTRY  *Link;
 LIST_ENTRY  *Head;
 IEVENT  *Event;

 CoreAcquireEventLock ();

 Head = &gEventSignalQueue;
 for (Link = Head->ForwardLink; Link != Head; Link = Link->ForwardLink) {
   Event = CR (Link, IEVENT, SignalLink, EVENT_SIGNATURE);
   if (CompareGuid (&Event->EventGroup, EventGroup)) {
  if ((Event->Type & EVT_NOTIFY_SIGNAL) != 0) {
   CoreNotifyEvent (Event);
 } else if (Event->SignalCount == 0x) {
  //
  // The check for 0 prevents double counting the signaled event. 
  //
  Event->SignalCount++;
 }
   }
 }

 CoreReleaseEventLock ();
}

Probably a good idea to change the name to CoreSignalEventGroup(). 

Thanks,

Andrew Fish

> -- Justin
>  
>  
> -Original Message-
> From: Andrew Fish [mailto:af...@apple.com]
> Sent: Friday, May 30, 2014 2:19 PM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] Signalling an event group
> 
> 
> On May 30, 2014, at 11:51 AM, Andrew Fish wrote:
> 
> > 
> > On May 30, 2014, at 11:00 AM, justin_johns...@dell.com wrote:
> > 
> >> Hello all,
> >> I’m working with the DXE core event services and am not sure that the code 
> >> in MdeModulePkg agrees with the UEFI spec.
> >> The situation is this: in several modules I have created an event using 
> >> the CreateEventEx() method, with an EventGroup GUID. Later, I want to 
> >> signal the event group, but the module which does the signaling does not 
> >> have any work to do in response to the event. It would seem that I can 
> >> signal the event by doing as indicated in the UEFI spec:
> >> gBS->CreateEventEx (
> >> 0,
> >> 0,
> >> NULL,
> >> NULL,
> >> &gMyEventGroupGuid,
> >> &Event);
> >> gBS->SignalEvent(Event);
> >> 
> >> However, this does not work with EDKII. I see in Event.c :
> >> if ((Event->Type & EVT_NOTIFY_SIGNAL) != 0) {
> >> if (Event->ExFlag) {
> >> //
> >> // The CreateEventEx() style requires all members of the Event Group
> >> // to be signaled.
> >> //
> >> CoreReleaseEventLock ();
> >> CoreNotifySignalList (&Event->EventGroup);
> >> CoreAcquireEventLock ();
> >> 
> >> Which seems to indicate that the event group is only signaled if the event 
> >> being signaled is of type EVT_NOTIFY_SIGNAL. In order to get my event 
> >> group signaled, I must create an event with a dummy callback and give it 
> >> type EVT_NOTIFY_SIGNAL, even though I do not have any work to do in 
> >> response to the event.
> >> 
> >> Is this an error in MdeModulePkg’s implementation? Or is the spec 
> >> incomplete?
> >> 
> 
> Justin,
> 
> I think the logic in the DXE Core should look like this:
> 
> if (Event->SignalCount == 0x) {
> Event->SignalCount++;
> 
> if (Event->ExFlag) {
> //
> // The CreateEventEx() style requires all members of the Event Group
> // to be signaled.
> //
> CoreReleaseEventLock ();
> CoreNotifySignalList (&Event->EventGroup);
> CoreAcquireEventLock ();
> } else if ((Event->Type & EVT_NOTIFY_SIGNAL) != 0) {
> //
> // If signalling type is a notify function, queue it
> //
> CoreNotifyEvent (Event);
> }
> }
> 
> So always walk the List for an Ex event, but only notify the event if it is 
> the right type. And the check should be in CoreNotifySignalList()
> 
> VOID
> CoreNotifySignalList (
> IN EFI_GUID *EventGroup
> )
> {
> LIST_ENTRY *Link;
> LIST_ENTRY *Head;
> IEVENT *Event;
> 
> CoreAcquireEventLock ();
> 
> Head = &gEventSignalQueue;
> for (Link = Head->ForwardLink; Link != Head; Link = Link->ForwardLink) {
> Event = CR (Link, IEVENT, SignalLink, EVENT_SIGNATURE);
> if (CompareGuid (&Event->EventGroup, EventGroup)) {
> if ((Event->Type & EVT_NOTIFY_SIGNAL) != 0) {
> CoreNotifyEvent (Event);
> }
> }
> }
> 
> CoreReleaseEventLock ();
> }
> 
> 
> Man, this code has been busted for a long time…. This bug predates the edk2!
> 
> The edk2 UefiLib even has a Dummy event and tries to hide the need for it 
> from the caller….
> 
> https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Library/UefiLib/UefiNotTiano.c
> /**
> An empty function to pass error checking of CreateEventEx ().
> 
> This empty function ensures that EVT_NOTIFY_SIGNAL_ALL is error
> checked correctly since it is now mapped into Create

Re: [edk2] Signalling an event group

2014-05-30 Thread Tim Lewis

Is this why we see a lot of created events with dummy notify functions?

-Original Message-
From: Andrew Fish [mailto:af...@apple.com] 
Sent: Friday, May 30, 2014 12:19 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Signalling an event group


On May 30, 2014, at 11:51 AM, Andrew Fish  wrote:

> 
> On May 30, 2014, at 11:00 AM, justin_johns...@dell.com wrote:
> 
>> Hello all,
>> I'm working with the DXE core event services and am not sure that the code 
>> in MdeModulePkg agrees with the UEFI spec.
>> The situation is this: in several modules I have created an event using the 
>> CreateEventEx() method, with an EventGroup GUID. Later, I want to signal the 
>> event group, but the module which does the signaling does not have any work 
>> to do in response to the event. It would seem that I can signal the event by 
>> doing as indicated in the UEFI spec:
>> gBS->CreateEventEx (
>>   0,
>>   0,
>>   NULL,
>>   NULL,
>>   &gMyEventGroupGuid,
>>   &Event);
>> gBS->SignalEvent(Event);
>>  
>> However, this does not work with EDKII. I see in Event.c :
>> if ((Event->Type & EVT_NOTIFY_SIGNAL) != 0) {
>>   if (Event->ExFlag) {
>> //
>> // The CreateEventEx() style requires all members of the Event Group
>> //  to be signaled.
>> //
>> CoreReleaseEventLock ();
>> CoreNotifySignalList (&Event->EventGroup);
>> CoreAcquireEventLock ();
>>  
>> Which seems to indicate that the event group is only signaled if the event 
>> being signaled is of type EVT_NOTIFY_SIGNAL. In order to get my event group 
>> signaled, I must create an event with a dummy callback and give it type 
>> EVT_NOTIFY_SIGNAL, even though I do not have any work to do in response to 
>> the event.
>>  
>> Is this an error in MdeModulePkg's implementation? Or is the spec incomplete?
>>  

Justin,

I think the logic in the DXE Core should look like this:

  if (Event->SignalCount == 0x) {
Event->SignalCount++;

if  (Event->ExFlag) {
//
// The CreateEventEx() style requires all members of the Event Group
//  to be signaled.
//
CoreReleaseEventLock ();
CoreNotifySignalList (&Event->EventGroup);
CoreAcquireEventLock ();
} else if ((Event->Type & EVT_NOTIFY_SIGNAL) != 0) {
//
// If signalling type is a notify function, queue it
//
CoreNotifyEvent (Event);
}
  }

So always walk the List for an Ex event, but only notify the event if it is the 
right type. And the check should be in CoreNotifySignalList()

VOID
CoreNotifySignalList (
  IN EFI_GUID *EventGroup
  )
{
  LIST_ENTRY  *Link;
  LIST_ENTRY  *Head;
  IEVENT  *Event;

  CoreAcquireEventLock ();

  Head = &gEventSignalQueue;
  for (Link = Head->ForwardLink; Link != Head; Link = Link->ForwardLink) {
Event = CR (Link, IEVENT, SignalLink, EVENT_SIGNATURE);
if (CompareGuid (&Event->EventGroup, EventGroup)) {
   if ((Event->Type & EVT_NOTIFY_SIGNAL) != 0) {
CoreNotifyEvent (Event);
  }
}
  }

  CoreReleaseEventLock ();
}


Man, this code has been busted for a long time This bug predates the edk2!

The edk2 UefiLib even has a Dummy event and tries to hide the need for it from 
the caller

https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Library/UefiLib/UefiNotTiano.c
/**
  An empty function to pass error checking of CreateEventEx ().

  This empty function ensures that EVT_NOTIFY_SIGNAL_ALL is error
  checked correctly since it is now mapped into CreateEventEx() in UEFI 2.0.
 
  @param  Event Event whose notification function is being 
invoked.
  @param  Context   The pointer to the notification function's 
context,
which is implementation-dependent.

**/
VOID
EFIAPI
InternalEmptyFunction (
  IN EFI_EVENTEvent,
  IN VOID *Context
  )
{
  return;
}

EFI_STATUS
EFIAPI
EfiCreateEventReadyToBootEx (
  IN  EFI_TPL   NotifyTpl,
  IN  EFI_EVENT_NOTIFY  NotifyFunction,  OPTIONAL
  IN  VOID  *NotifyContext,  OPTIONAL
  OUT EFI_EVENT *ReadyToBootEvent
  )
{
  EFI_STATUSStatus;
  EFI_EVENT_NOTIFY  WorkerNotifyFunction;

  ASSERT (ReadyToBootEvent != NULL);

  if (gST->Hdr.Revision < EFI_2_00_SYSTEM_TABLE_REVISION) {
DEBUG ((EFI_D_ERROR, "EFI1.1 can't support ReadyToBootEvent!"));
ASSERT (FALSE);

return EFI_UNSUPPORTED;
  } else {
//
// For UEFI 2.0 and the future use an Event Group
//
if (NotifyFunction == NULL) {
  //
  // CreateEventEx will check NotifyFunction is NULL or not and return 
error.
  // Use dummy routine for the case NotifyFunction is NULL.
  //
  WorkerNotifyFunction = InternalEmptyFunction;
} else {
  WorkerNotifyFunction = NotifyFunction;
}
Status = gBS->CreateEventEx (
EVT_NOTIFY_SIGNAL,
NotifyTpl,

Re: [edk2] Signalling an event group

2014-05-30 Thread Tim Lewis

Andrew--

It accounts for the strange usage I've seen. When the code wants to signal the 
event group, it also has to create an event in the event group. With the 
current codebase, you can see it creating dummy notify functions for this 
event, even though the intention is just to signal the other events in the 
group. For example, see IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c, 
line 144 where it has the usefully-titles reference to 
"BdsEmptyCallbackFunction" or ConSpliter.c (line 590) with 
"ConSplitterEmptyCallbackFunction". Even DXE Core's CoreEmptyCallbackFunction 
in Event.c (line 142)

I could not find anything in CreateEventEx that tries to enforce this, which is 
good.

Tim

-Original Message-
From: Andrew Fish [mailto:af...@apple.com] 
Sent: Friday, May 30, 2014 1:15 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Signalling an event group


On May 30, 2014, at 12:41 PM, justin_johns...@dell.com wrote:

> Andrew,
> Your suggested code makes sense to me, I will give it a try. Besides that 
> sample code snippet, I don't think the spec isn't really explicit; but does 
> imply that the entire group is signaled, regardless of whether the event 
> itself is of type EVT_NOTIFY_SIGNAL.
>  

The reason CreateEventEx() got created was to allow the signaling of a group of 
functions so they could run their notify function. But the example clearly 
shows it is legal to create and Ex event of any type. The spec does say the 
event is signaled and their notification functions are schedule. 

Good point, if all the events got signaled I think CoreNotifySignalList() would 
look more like:

VOID
CoreNotifySignalList (
 IN EFI_GUID *EventGroup
 )
{
 LIST_ENTRY  *Link;
 LIST_ENTRY  *Head;
 IEVENT  *Event;

 CoreAcquireEventLock ();

 Head = &gEventSignalQueue;
 for (Link = Head->ForwardLink; Link != Head; Link = Link->ForwardLink) {
   Event = CR (Link, IEVENT, SignalLink, EVENT_SIGNATURE);
   if (CompareGuid (&Event->EventGroup, EventGroup)) {
  if ((Event->Type & EVT_NOTIFY_SIGNAL) != 0) {
   CoreNotifyEvent (Event);
 } else if (Event->SignalCount == 0x) {
  //
  // The check for 0 prevents double counting the signaled event. 
  //
  Event->SignalCount++;
 }
   }
 }

 CoreReleaseEventLock ();
}

Probably a good idea to change the name to CoreSignalEventGroup(). 

Thanks,

Andrew Fish

> -- Justin
>  
>  
> -Original Message-
> From: Andrew Fish [mailto:af...@apple.com]
> Sent: Friday, May 30, 2014 2:19 PM
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] Signalling an event group
> 
> 
> On May 30, 2014, at 11:51 AM, Andrew Fish wrote:
> 
> > 
> > On May 30, 2014, at 11:00 AM, justin_johns...@dell.com wrote:
> > 
> >> Hello all,
> >> I'm working with the DXE core event services and am not sure that the code 
> >> in MdeModulePkg agrees with the UEFI spec.
> >> The situation is this: in several modules I have created an event using 
> >> the CreateEventEx() method, with an EventGroup GUID. Later, I want to 
> >> signal the event group, but the module which does the signaling does not 
> >> have any work to do in response to the event. It would seem that I can 
> >> signal the event by doing as indicated in the UEFI spec:
> >> gBS->CreateEventEx (
> >> 0,
> >> 0,
> >> NULL,
> >> NULL,
> >> &gMyEventGroupGuid,
> >> &Event);
> >> gBS->SignalEvent(Event);
> >> 
> >> However, this does not work with EDKII. I see in Event.c :
> >> if ((Event->Type & EVT_NOTIFY_SIGNAL) != 0) { if (Event->ExFlag) { 
> >> // // The CreateEventEx() style requires all members of the Event 
> >> Group // to be signaled.
> >> //
> >> CoreReleaseEventLock ();
> >> CoreNotifySignalList (&Event->EventGroup); CoreAcquireEventLock ();
> >> 
> >> Which seems to indicate that the event group is only signaled if the event 
> >> being signaled is of type EVT_NOTIFY_SIGNAL. In order to get my event 
> >> group signaled, I must create an event with a dummy callback and give it 
> >> type EVT_NOTIFY_SIGNAL, even though I do not have any work to do in 
> >> response to the event.
> >> 
> >> Is this an error in MdeModulePkg's implementation? Or is the spec 
> >> incomplete?
> >> 
> 
> Justin,
> 
> I think the logic in the DXE Core should look like this:
> 
> if (Event->SignalCount == 0x) {
> Event->SignalCount++;
> 
> if (Event->ExFlag) {
> //
> // The CreateEventEx() style requires all members of the Event Group 
> // to be signaled.
> //
> CoreReleaseEventLock ();
> CoreNotifySignalList (&Event->EventGroup); CoreAcquireEventLock (); } 
> else if ((Event->Type & EVT_NOTIFY_SIGNAL) != 0) { // // If signalling 
> type is a notify function, queue it // CoreNotifyEvent (Event); } }
> 
> So always walk the List for an Ex event, but only notify the event if 
> it is the right type. And the check should be in 
> CoreNotifySignalList()
> 
> VOID
> CoreNotifySignalList (
> IN EFI_GUID *EventGroup
> )
> {
> LIST_ENTRY *Link;

[edk2] How to add Unicode string in EDKII

Re: [edk2] ReinstallProtocolInterface to notify filesystem driver?

Re: [edk2] Minnowboard and UDK debugger 1.4.

Re: [edk2] UEFI Development Board

[edk2] [PATCH] edksetup: Fix EDK_TOOLS_PATH misbehaving

Re: [edk2] How to add Unicode string in EDKII

Re: [edk2] ReinstallProtocolInterface to notify filesystem driver?

Re: [edk2] ReinstallProtocolInterface to notify filesystem driver?

[edk2] Signalling an event group

Re: [edk2] Signalling an event group

Re: [edk2] Signalling an event group

Re: [edk2] Signalling an event group

Re: [edk2] Signalling an event group

Re: [edk2] Signalling an event group

Re: [edk2] Signalling an event group

15 matches

Site Navigation

Mail list logo

Footer information