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]>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.
>
> 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]]
> Sent: Friday, January 25, 2013 4:11 PM
> To: [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]]
> Sent: Friday, January 25, 2013 4:20 PM
> To: [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]]
> Sent: Friday, January 25, 2013 9:26 AM
> To: [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]]
> Sent: Thursday, January 24, 2013 10:01 PM
> To: [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, 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]
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, 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]
> 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
