Global variables in system programs

[Alfred Perlstein]

On 10/15/13 8:57 AM, Ian Lepore wrote:
> On Tue, 2013-10-15 at 08:44 -0700, Alfred Perlstein wrote:
>> On 10/15/13 8:07 AM, Sebastian Huber wrote:
>>> Hello,
>>>
>>> I work currently on a port of the FreeBSD network stack to a real-time
>>> operating system for embedded targets.  Here the applications are
>>> statically linked with the operating system and the network stack.  We
>>> would like to use the standard FreeBSD system programs to configure
>>> the network stack, e.g. ROUTE(8), IFCONFIG(8), etc.  For example
>>>
>>> static const char *const argv[] = {
>>>    "ifconfig",
>>>    "lo0",
>>>    "127.0.0.1"
>>> };
>>>
>>> ifconfig(3, &argv[0]);
>>>
>>> These programs use some global variables.  In a statically linked
>>> context we have now the following problems
>>>
>>> o we cannot call the programs concurrently,
>>>
>>> o we have to initialize the values each time.
>>>
>>> We would like to follow the FreeBSD sources to stay up-to-date. So it
>>> is desirable for us to keep the divergence from the original sources
>>> as small as possible.  Are patches acceptable for the FreeBSD project
>>> that alter system programs such that
>>>
>>> o global variables are moved into context structures,
>>>
>>> o constant global variables are declared as "const", and
>>>
>>> o variables and functions are declared as "static" if possible?
>>>
>>> Attached is a patch for the ROUTE(8) program to give an example.
>> Wow!  I would really love to see this sort of change make it into
>> FreeBSD, not only for linking them all together, but also for running
>> them as threads.
> Another factor in trying to turn standalone programs into threads
> bundled into a larger entity:  by design, we do not free allocated
> memory, we let program-exit handle that.
>
> The const and static changes are great.  The context thing I'm not so
> fond of.  Might there be a way to handle these bundled-in programs a bit
> like .ko modules somehow?  They can be compiled-in, but invoking one
> would result in re-initing its data and bss, and because they're still
> compiled separately and then bundled in later (somehow, see my hands
> wave here).  Compiling them separately would fix the namespace clash
> problems.  Maybe it would even pave the way to handle the malloc/free
> problem, if it could be made to run in some sort of sandboxed
> environment that would allow resources to be freed -- it just occurred
> to me it's not just malloc, it's file descriptors and signal handling
> environment and maybe other things I'm not thinking of right now).
Yes!  You are very correct.

One step at a time we can realize this goal.

Apache apr library uses the concepts of pools to attach resources to 
certain lifecycles.  Maybe we can do this?  I think Peter just pulled in 
some form of apr into base.

Other options are using a form of per-thread data that sets an implicit 
pool for resource tracking.

-Alfred