Global variables in system programs

[Sebastian Huber]

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?

>
> 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.

This is not a problem for us.  Its easy to add custom set up and tear down code 
without modifying the original FreeBSD sources.  We write unit tests that 
ensure that we have no resource leaks.  We also have to map all calls to exit() 
to a wrapper function which uses longjmp() to jump to a common program 
termination section which later returns to the caller of the main() function.

>
> The const and static changes are great.

This would definitely help a lot.  Some applications run from flash, so 
everything which lands in the read-only data section saves RAM space.  Turning 
the global functions into static ones will likely affect the code generation. 
Is this a problem?

What about changing the K&R function declarations into standard ones?

> 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?

I want to avoid a run-time linker.

I think that global static variables are not a real problem for us.  We can 
simply use a mutex and allow at most one invocation of the program at once.  A 
local context is a nice-to-have feature.

> 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).
>
> -- Ian
>
>
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>


-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.