Global variables in system programs

[Ian Lepore]

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

-- Ian