Re: [edk2] Tianocore & Google Summer of Code

Subject: Re: [edk2] Tianocore & Google Summer of Code

From: "Brian J. Johnson" <bjohnson@sgi.com>

To: edk2-devel@lists.sourceforge.net

Date: 2011-03-07 17:36:57

On 03/05/2011 01:19 PM, Andrew Fish wrote:
> Jordan,
>
> Thanks again for helping fix my Linux build break due to us adding the Berkeley Packet Filter (BPF) for networking support. I did not realizing the way Linux worked was different. On a more positive note this made me think about some Summer of Code projects....
>
> Possible Tianocore&  Google Summer of Code projects:
> 1) Port the UnixPkg to support Linux Socket Filtering (LSF), in addition to BPF. Looks like conceptually LSF is modeled on BPF so it should be a good template of what needs to be done.
>
> 2) Add infrastructure to support MP safe Print, DEBUG, and ASSERT on APs. Library functions to help APs share data with the BSP. With a white paper on how to code MP UEFI/PI programs.
>
> I've not contributed this yet but I've added MP support (Up to 9 APs) via pthreads to the emulator. Basically I have the CPU driver produce a MP Services protocol that abstracts all the pthread stuff. I also added some debug code to the DXE Core that uses the MP Services protocol to detect is a boot service is called from an AP and force a breakpoint.  When I catch up with my real work I hope to clean this up and contribute to the edk2.
>
> 3) Per my __builtin_return_address(n)/_ReturnAddress post a debug versions of various libraries would be useful. There are lots of possibilities:
> a) produce a protocol with info on the image handle so a shell command can dump out the information
> b) track, on a per call basis, were resources are being consumed.
> c) detect memory leaks
> d) log information about stall and timer usage
> e) Collect statistics on Bootservices and Runtime services calls.
> f) Performance profile library calls EFI boot and runtime services calls.
> 	1) gBS is set up by a library so it could point to a debug wrapper for the functions.
> g) Post process raw output (PDB name + offset in PE/COFF) to include function names via parsing .map files.

WINE (http://www.winehq.org/) has fairly complete code for parsing .pdb 
files in their dbghelp DLL implementation.  You could probably get 
function and line number information pretty easily from the .pdb's using 
their code as a guide. 
http://source.winehq.org/git/wine.git/?a=tree;f=dlls/dbghelp;hb=HEAD

> h) ....

A few additional suggestions:

- A fully functional gdb stub for x86/x64, attaching to 
SourceLevelDebugPkg's remote protocol
- Terminal driver improvements:  optimize cursor motion sequences, 
support Linux/UNIX standard (xterm/konsole/gnome-terminal/etc.) key 
codes and line-drawing characters.
- A command-line based HII browser, suitable for automation.  Either a 
shell command or set of commands for locating, dumping, and modifying 
configuration values, or commands for dumping and loading HII data 
to/from a file in an easily-edited format.
- Detect boot time data which may potentially be accessed at runtime.
- A CSM implementation, maybe based on SeaBIOS 
(http://www.coreboot.org/SeaBIOS). SeaBIOS is GPL/LGPL licensed, so it 
couldn't be used directly in TianoCore's BSD licensed sources.  But 
perhaps a BSD-licensed wrapper could be written, or the SeaBIOS mods. 
could be hosted separately....
- Add a pool allocator to PEI which supports freeing and reclaiming 
memory.  Or maybe that requires PI spec work?
- The DataHub and GCD layers don't scale well as the number of data 
items gets large, since they are based on simple linked lists.  Find 
better data structures (may require the profiling support Andrew 
mentioned above)
- Port SheepShaver (http://sheepshaver.cebix.net/) as an EFI 
application.  :)
-- 

                                                 Brian J. Johnson

--------------------------------------------------------------------

    "The public needs NREN because 300 baud used to be fast and low-
     resolution graphics used to be pretty....  We wait impatiently,
     sure that we spend half our lives waiting for printers, and the
     other half waiting for disk drives.  Time is a commodity."
                                            -- Jean Armour Polly

------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel