FWIW, I had to move the Constructor and Destructor out of Main.c / LibC.inf
(LibC) and instead add a new LibCInit.inf (LibCInit) and LibCInit.c file
which depends on only the core UEFI stuff and DevConsole otherwise it kept
always calling the LibC constructor prior to DevConsole even when I tried
to remove all dependencies to LibC in any way from DevConsole.
On Wed, Sep 11, 2013 at 12:56 PM, Mcdaniel, Daryl
<daryl.mcdan...@intel.com>wrote:
> David,****
>
> ** **
>
> What you describe is similar to what I have been thinking of doing for the
> standalone StdLib. CLib would actually be a UEFI driver that initialized a
> smaller version of the MainData structure and only contained those items
> required for ANY StdLib application.****
>
> ** **
>
> Some of the MainData members that are owned exclusively by a particular
> library, such as the string library’s buffers, would be moved from MainData
> into that library’s dynamic data structure.****
>
> ** **
>
> Every application that uses the “CLib” driver would have its own dynamic
> data structure(s) but use the “shared” code. (The few static variables are
> also being removed) This will make it easier to add dynamic loading for
> Python modules and to support things like threading and POSIX-style
> environment inheritance.****
>
> ** **
>
> It isn’t fully implemented yet, but device libraries such as DevShell,
> DevConsole, DevTTY, etc. are intended to add OPTIONAL functionality to
> StdLib. Thus, the dependencies flow from the device libraries to StdLib.
> StdLib can be used without any of the device libraries, with a resultant
> reduction of functionality. For example, without DevShell, you don’t have
> access to the Shell-hosted file sytem. But, if you use DevSFS instead, you
> gain access to the filesystems using the standalone functionality.
> Similarily, DevConsole can be either replaced, or supplemented, by DevTTY
> to add serial port support. A headless application could be developed that
> uses none of the “Dev*” class libraries.****
>
> ** **
>
> All of these changes are being done in such a way that they are
> transparent to application developers.****
>
> ** **
>
> Daryl McDaniel
>
> *"I have always wished for my computer to be as easy to use as my
> telephone;*
>
> *my wish has come true because I can no longer figure out how to use my
> telephone."*
>
> *-- Bjarne Stroustrup*
>
> ****
>
> ** **
>
> *From:* David F. [mailto:df7...@gmail.com]
> *Sent:* Wednesday, September 11, 2013 9:18 AM
> *To:* edk2-devel@lists.sourceforge.net
> *Subject:* [edk2] stdlib dependencies****
>
> ** **
>
> Hi,****
>
> I need CLib to be available prior to calling ShellAppMain that way all the
> CPP static constructors and any pre main setup stuff (mounting file system
> which may want to use stdlib functions, etc..) can be done. So my thought
> is to take part of ShellAppMain and make it __ctor_CLib for init and
> __dtor_CLib for term (but leaving the file close processing in ShellAppMain
> because any file access would be coming after the __ctor at this point).
> Then other things can also be __ctor and depend on CLib (just right now
> anything wanting file access would fail since nothing mounted).. However
> looking at some of the other constructors in stdlib, such as devshell, they
> depend on CLib whereas I would think CLib should depend on it (for
> construction ordering anyway). I think for now I'll just not make cpp
> initialization and the others a constructor, but call them in the program
> entry point prior to ShellAppMain being called because I don't know where
> you guys are going with the version that removes shell dependance and don't
> want to move too far away for updates (I've already detached from the shell
> myself .. pretty easy, from what I recall replace contents of daShell,
> comment out the get/put env and link to your own.). Any updates? May
> want to look at using a constructor for clib (main) and check constructor
> ordering...
>
>
>
> ****
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. Consolidate legacy IT systems to a single system of record for IT
> 2. Standardize and globalize service processes across IT
> 3. Implement zero-touch automation to replace manual, redundant tasks
> http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
