From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 17 09:09:21 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 A259782E for ; Thu, 17 Oct 2013 09:09:21 +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 1B9DD2E6C for ; Thu, 17 Oct 2013 09:09:20 +0000 (UTC) Received: by mail.embedded-brains.de (Postfix, from userid 65534) id 35DA5652CFB; Thu, 17 Oct 2013 11:09:11 +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 02E4765219E; Thu, 17 Oct 2013 11:09:08 +0200 (CEST) Message-ID: <525FA92E.40506@embedded-brains.de> Date: Thu, 17 Oct 2013 11:09:02 +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: Eitan Adler Subject: Re: Global variables in system programs References: <525D5A35.4040005@embedded-brains.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 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: Thu, 17 Oct 2013 09:09:21 -0000 On 2013-10-17 03:45, Eitan Adler wrote: > On Tue, Oct 15, 2013 at 11:07 AM, Sebastian Huber > wrote: > >> These programs use some global variables. In a statically linked context we >> have now the following problems > > This is a pretty awesome idea. I've seen some work like this but it > would be great to get FreeBSD into a state where this is easy. If it is acceptable for the FreeBSD project to turn e.g. ROUTE(8) and IFCONFIG(8) into library functions then this would be great. I can do the work. As noted in a different mail, currently no resource clean up is performed. Adding such code will make the program more complex. Another problem is the usage of exit(). I address this for our wrapper with something like this: /** * @defgroup ExitWrap Exit Wrap * * @brief Wrap the exit() function to support self-contained programs. * * @code * extern some_main(int argc, char **argv); * * int call_some_main(int argc, char **argv) * { * exit_wrap_control ewctrl; * int exit_code; * * if (exit_wrap_initialize(&ewctrl)) { * exit_code = some_main(argc, argv); * } else { * exit_code = exit_wrap_get_exit_code(&ewctrl); * } * * exit_wrap_destroy(&ewctrl); * * return exit_code; * } * @endcode * * @{ */ typedef struct { jmp_buf return_context; int exit_code; } exit_wrap_control; static inline bool exit_wrap_initialize( exit_wrap_control *self ) { self->exit_code = EXIT_FAILURE; return setjmp(self->return_context) == 0; } static inline void exit_wrap( exit_wrap_control *self, int exit_code ) { self->exit_code = exit_code; longjmp(self->return_context, 1); } static inline int exit_wrap_get_exit_code( const exit_wrap_control *self ) { return self->exit_code; } static inline void exit_wrap_destroy( exit_wrap_control *self ) { (void) self; } > > Are patches acceptable for the FreeBSD project that alter >> system programs such that > > >> o global variables are moved into context structures, > > Provided that the code remains readable I think these would be fine. > >> o constant global variables are declared as "const", and >> o variables and functions are declared as "static" if possible? > > There has been a lot of work on this area. Your patch surprises me > because I see many changes which were already done. We would > absolutely be interested in such patches Oh, sorry. This patch was generated against the FreeBSD 8.2 version. Yes, the current ROUTE(8) looks vastly different and the above two problems have been addressed. One minor problem: static const char *msgtypes[] = { "", "RTM_ADD: Add Route", [...] "RTM_IEEE80211: IEEE 802.11 wireless event", }; This should be probably: static const char *const msgtypes[] > >> Attached is a patch for the ROUTE(8) program to give an example. > > This patch can not apply for instance > > patchfile: > 960 > 961 -char metricnames[] = > 962 +static const char metricnames[] = > 963 "\011weight\010rttvar\7rtt\6ssthresh\5sendpipe\4recvpipe\3expire" > 964 "\1mtu"; > > but actual file: > > 1557 static const char metricnames[] = > 1558 "\011weight\010rttvar\7rtt\6ssthresh\5sendpipe\4recvpipe\3expire" > 1559 "\1mtu"; > > > If you can generate patches against HEAD that would be great. > > I notice you use git: try to generate patches against > https://github.com/freebsd/freebsd > > I use this Git repository, but currently I work with the FreeBSD 8.2 branch. The network stack port is a long running stuff for us. The goal is to first get the existing work unit tested and then move to the latest FreeBSD release. -- 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.