From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 16 08:12:44 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 06721DCC; Wed, 16 Oct 2013 08:12:44 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from mail.embedded-brains.de (host-82-135-62-35.customer.m-online.net [82.135.62.35]) by mx1.freebsd.org (Postfix) with ESMTP id 177C9293F; Wed, 16 Oct 2013 08:12:42 +0000 (UTC) Received: by mail.embedded-brains.de (Postfix, from userid 65534) id 25E42652CFE; Wed, 16 Oct 2013 10:12:38 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on fidibusdmz X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from [192.168.100.11] (unknown [192.168.100.11]) by mail.embedded-brains.de (Postfix) with ESMTP id 17F4765253A; Wed, 16 Oct 2013 10:12:36 +0200 (CEST) Message-ID: <525E4A6F.40904@embedded-brains.de> Date: Wed, 16 Oct 2013 10:12:31 +0200 From: Sebastian Huber User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Global variables in system programs References: <525D5A35.4040005@embedded-brains.de> <525D62D9.4050001@freebsd.org> <1381852662.42859.130.camel@revolution.hippie.lan> In-Reply-To: <1381852662.42859.130.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Hackers , Alfred Perlstein X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 08:12:44 -0000 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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@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@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.