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
