From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 15 16:02:44 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A075B823; Tue, 15 Oct 2013 16:02:44 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 8D7702268; Tue, 15 Oct 2013 16:02:44 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 1A7C61A3C74; Tue, 15 Oct 2013 09:02:44 -0700 (PDT) Message-ID: <525D6724.9020307@freebsd.org> Date: Tue, 15 Oct 2013 09:02:44 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 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: 7bit Cc: Sebastian Huber , FreeBSD Hackers 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: Tue, 15 Oct 2013 16:02:44 -0000 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