[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft-devel] Position Independent Port of FreeType2
From: |
Mickey Gabel |
Subject: |
Re: [ft-devel] Position Independent Port of FreeType2 |
Date: |
Wed, 21 Jan 2009 19:29:45 +0200 |
User-agent: |
Thunderbird 2.0.0.19 (Windows/20081209) |
The sample diffs are on the way (still tweaking), but in the meanwhile
what about the following idea.
Let's assume that:
A) We are making a version of FT2 where const global data containing
pointers is not allowed ("PIC" mode).
B) All the various function tables, structs, etc. Must move into some
structure that is allocated. Either an into an existing structure, or
just a pointer inside an existing structure.
C) The global data was previously easily accessible (it was just a
symbol so every module could access it). Therefore the new location of
this data must still be relatively easily accessible.
D) Most of the code in FT2 (that contains global data that needs to be
moved) resides inside a module (or a renderer/driver) and therefore
there is a FT_Module_Class with an init function somewhere.
E) A module's init function is called before any other work with the
module or its global data is done. The module_done function is called
after all work with the module is done.
(Do these assumptions hold true? are they MOSTLY correct?)
The idea:
Each module can put its own const global data in its FT_Module_Class.
The module's initialization/constructor function (module_init) is
responsible for initialization of the global data that was moved. I
assume that code in module X can easily get to the relevant
FT_Module_Class for that class, via walking the pointer graph.
Of course, the actual module table (as well as base code) still needs to
be moved into SOMEWHERE. This somewhere can probably be in the LibraryRec.
The module list (the table containing the various FT_Module_Class
pointers, etc) will be initialized during FT_New_Library(). Same with
other global data used by the base code.
It seems to be that this method has the following advantages:
a) modular. Module X doesn't need to know about Module Y's internal data.
b) at least for modules (which are most of the code, see assumption D)
there is a single, easy entry point to add initializations. No
dependencies of the base code on the modules.
C) again, for modules if some build of the library doesn't include
module Z, then module Z's global data is not allocated.
Please note that INSIDE each module, the solution would have to be
tailored specifically for how the module uses the global data.
I know this is kind of vague at this point without a working example,
but still, any comments? Especially, am I assuming too much or missing
something?
- [ft-devel] Position Independent Port of FreeType2, Mickey Gabel, 2009/01/20
- Re: [ft-devel] Position Independent Port of FreeType2, Dmitry Timoshkov, 2009/01/20
- Re: [ft-devel] Position Independent Port of FreeType2, Mickey Gabel, 2009/01/20
- Re: [ft-devel] Position Independent Port of FreeType2, mpsuzuki, 2009/01/20
- Re: [ft-devel] Position Independent Port of FreeType2, Werner LEMBERG, 2009/01/20
- Re: [ft-devel] Position Independent Port of FreeType2, Mickey Gabel, 2009/01/21
- Re: [ft-devel] Position Independent Port of FreeType2,
Mickey Gabel <=
- Re: [ft-devel] Position Independent Port of FreeType2, Werner LEMBERG, 2009/01/22
- Re: [ft-devel] Position Independent Port of FreeType2, Mickey Gabel, 2009/01/22
- Re: [ft-devel] Position Independent Port of FreeType2, Mickey Gabel, 2009/01/22
- Re: [ft-devel] Position Independent Port of FreeType2, Werner LEMBERG, 2009/01/23
- Re: [ft-devel] Position Independent Port of FreeType2, Mickey Gabel, 2009/01/23
- Re: [ft-devel] Position Independent Port of FreeType2, Werner LEMBERG, 2009/01/23