Krishna,
It is not available on the Trunk, yet.
I am finishing up the standalone file-system and console this week.
Key features of this update:
* No runtime dependency on the Shell or shell protocol
* Device mapping compatibility with the Shell for:
o File system devices - FS#
o Block devices - BLK#
o Consistent mapping names
* FS0: will automatically be selected as the default file system
* Each file system will have its own Current Working Directory
o Default (initial) path is "\"
o Updated whenever the chdir() function is called
* Better handling of UTF-16 and UTF-8 character streams
There are still a few system calls and other library routines with Shell
dependencies. They are next to be addressed.
Finally, there are some environmental requirements from the C standard
resulting in a lot of library interdependencies. As a final step, I will be
making the libraries as independent as possible.
Currently, the LibCtype, LibTime, and LibWhar libraries have no dependencies.
They can be used without any other StdLib libraries or other operational
dependencies.
As I finish each phase, the code will be tested, reviewed, then committed to
the EDK II Trunk on www.tianocore.org<http://www.tianocore.org>.
Each of the updates will be announced on this mail list.
I am still accepting "Wish List" items for functionality to add to StdLib.
Some of the suggestions include a regular expression library, for C, and
dynamic loading for Python.
Daryl McDaniel
"I don't know the key to success, but the key to failure is trying to please
everybody"
-- Bill Cosby.
From: s.v.krishna reddy [mailto:[email protected]]
Sent: Monday, December 16, 2013 4:53 AM
To: [email protected]
Subject: Re: [edk2] StdLib & Drivers & non-Shell Apps
Hi Daryl,
I'm not sure whether this is completed. Could you confirm whether Standalone
LIBC for DXE drivers available on the Trunk?
Thanks,
Krishna.
On Sat, Jan 26, 2013 at 8:02 AM, Mcdaniel, Daryl
<[email protected]<mailto:[email protected]>> wrote:
Luis,
Unfortunately, all I can say is that I am working on it.
If you, or anyone else reading this list, have any specific items in your "wish
list" for StdLib, please post it to the list.
I can't say that everything will be incorporated, but my primary goal is to
make the libraries as useful to the community as possible.
The "driver friendly", or Standalone, version of StdLib will supplement or
replace the existing StdLib on www.tianocore.org<http://www.tianocore.org>.
Daryl McDaniel
"In the pun, two strings of thought are tangled into one acoustic knot."
-- Arthur Koestler
-----Original Message-----
From: Pollo, Luis Fernando [mailto:[email protected]<mailto:[email protected]>]
Sent: Friday, January 25, 2013 4:11 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] StdLib & Drivers & non-Shell Apps
Hi Daryl,
A driver-friendly StdLib is great news! Sorry if this has been discussed on the
list before, but are you planning to release this as part of TianoCore? If so,
when do you think it would be available?
Thanks,
Luis
________________________________
From: Tim Lewis [[email protected]<mailto:[email protected]>]
Sent: Friday, January 25, 2013 4:20 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] StdLib & Drivers & non-Shell Apps
Daryl -
I would also point out that there is a difference between UEFI applications and
UEFI drivers, for the purposes of the C library. For example, UEFI applications
share entry point styles with UEFI shell apps, not drivers, UEFI applications
can still get command-line arguments (in many cases), UEFI applications can
still redirect ConIn/ConOut/ErrOut and can still use file systems, all without
using the UEFI shell API.
Also UEFI applications are not likely to use a driver/protocol, since they
often exist on a disk rather than built-in the ROM and may not be used in a
system which has the protocol. And the size overhead for containing both
branches of code can be a problem, so a FeatureFlag PCD would be preferable.
Tim
From: Mcdaniel, Daryl
[mailto:[email protected]<mailto:[email protected]>]
Sent: Friday, January 25, 2013 9:26 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [edk2] StdLib & Drivers & non-Shell Apps
For the Standalone StdLib, which I am working on, I take the approach that one
will modify the library class definitions in the project's .dsc file to point
to either the Shell hosted or the Standalone library instances. Once finished,
the Standalone libraries will be able to be used in drivers as long as their
UEFI dependencies are met. The two sets of libraries are
The way things are currently working out, the only library that will be
different is LibC since the refactored, standalone, libraries are the same for
both hosted and standalone environments.
The benefit to this is that the change(s) needed to go between hosted or
standalone is confined to a single file; the project .dsc file.
So, my vote is for you to keep the library classes the same and select between
the implementation instances in the [LibraryClasses] section of the .dsc file.
The Standalone StdLib also installs itself as a driver/protocol (if that build
option was set) so that the overhead is only incurred once if there are
multiple drivers or applications using StdLib.
Daryl
From: Tim Lewis [mailto:[email protected]<mailto:[email protected]>]
Sent: Thursday, January 24, 2013 10:01 PM
To:
[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>
Subject: [edk2] StdLib & Drivers & non-Shell Apps
Folks - I am fairly far along in creating a basic version of the StdLib which
works for Drivers and non-Shell apps. Yes, there are many functions that are
missing, but good ol' malloc/free and strcpy are there.
The troubling case seems to be non-shell UEFI applications. Because both shell
and non-shell applications compile as UEFI_APPLICATION, I can't use
LibraryClass to distinguish between them. Yes, I can tell between them at
runtime by whether or not the Shell protocols are present. But it requires that
I link against the ShellPkg, and takes up extra space, even if the app is
designed to be run directly from the UEFI Boot Manager (with the App bit set in
the load option, etc.) For drivers, the LibraryClass idea works fine for
excluding unnecessary code and the dependency on the shellpkg.
So, is my only option to create another whole library class (LibCApp?) along
with the library classes for LibStdLibApp, LibStdioApp, etc.
I think that this effort is very useful, because I port a lot of code back and
forth between shell apps and drivers and non-UEFI. From an architecture
standpoint, I could see adding a new MODULE_TYPE (UEFI_BOOT_APPLICATION).
Any other ideas?
Tim
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET<http://ASP.NET>, C# 2012, HTML5,
CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
edk2-devel mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET<http://ASP.NET>, C# 2012, HTML5,
CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
edk2-devel mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
