Global variables in system programs

[Alfred Perlstein]

On 10/16/13 1:12 AM, Sebastian Huber wrote:
> On 2013-10-15 17:57, 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.
>
> Out of curiosity, what is the benefit of running these programs in a 
> thread in case you have an operating system with proper processes?

Imagine a program or some shell which loads a bunch of shared objects so 
instead of needing to fork/exec for each command can just dispatch to a 
thread.

It would let that program be very fast as opposed to a traditional 
fork/exec model.

-Alfred