On Mar 18, 2014, at 4:32 AM, Rafael Machado <rafaelrodrigues.mach...@gmail.com> 
wrote:

> Hi Everyone
> 
> Thanks for the answers.
> Another point that come during my last meeting with my teacher was (This will 
> be a polemical question):
> 
> "If the idea is to have a fast way to boot the system and execute some 
> parallel task, wouldn't it be better create a Linux minimal image ?

In a lot of cases yes. You do run into the issue of having to install the OS. 

> Doing the development of the mp services in future someone will create a 
> scheduler, aren't we creating another operating system, prior to the "real" 
> operating system (windows, linux,....) ? "
> 

Well this brings up another key point. EFI is Event Driven, not threaded. So 
EFI does not have a scheduler on the boot processor.  We picked an event model 
as it is more deterministic and simpler to program and get right. Determinism 
is important especially on prototype hardware as you tend to crash in the same 
place when the hardware is busted. 

While we found this presentation many years after we decide the event model was 
the way to go, we find it helps to educate those who say EFI is broken since it 
does not support threads: 
http://www.cc.gatech.edu/classes/AY2009/cs4210_fall/papers/ousterhout-threads.pdf


> My was that UEFI was created to standardize the firmware interfaces, and that 
> it's faster than a minimal Linux, but I didn't have the answer about opening 
> a door to create another kind of "UEFI OS" being executed before the real 
> system OS (windows, linux,....)
> 

An OS, with a scheduler, is really really good at loading and stressing a 
system. It is often difficult to debug hardware failures when the OS crashes. 

> Does anyone here have a good reason for creating the MP services ?

Well the MpService protocol 
(https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Include/Protocol/MpService.h)
 exists on a lot of platforms today.  It is hard to use as EFI is only safe to 
run on the boot processor. Not even DEBUG prints and ASSERTs are MP safe. 

> and Why creating it is really needed ?
> 

The value to creating a more robust MP environment in the PI world 
(http://en.wikipedia.org/wiki/Platform_Initialization_Specification) is to 
enable deterministic diagnostics. For example is a scheduler is running you can 
not get a cache into a known state. While the OS helps, it can also get in the 
way of a certain class of tests that require determinism. 

The boot firmware may also run into to a computationally complex, or high 
memory bandwidth, task that requires it to use MP services. Perhaps there is a 
very large file that needs to be decompressed (OS install/recovery image), or a 
robust memory test may be required on certain boots. 

The biggest issue with writing MP PI code is most of the times it is not done 
correctly. Some non MP safe library function ends up getting called and it is 
just luck that it works.

Thanks,

Andrew Fish

> Thanks everyone for the help.
> Rafael R. Machado

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Reply via email to