Date: Tue, 15 Oct 2013 09:02:44 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: Ian Lepore <ian@FreeBSD.org> Cc: Sebastian Huber <sebastian.huber@embedded-brains.de>, FreeBSD Hackers <freebsd-hackers@FreeBSD.org> Subject: Re: Global variables in system programs Message-ID: <525D6724.9020307@freebsd.org> In-Reply-To: <1381852662.42859.130.camel@revolution.hippie.lan> References: <525D5A35.4040005@embedded-brains.de> <525D62D9.4050001@freebsd.org> <1381852662.42859.130.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?525D6724.9020307>