From owner-freebsd-arch@FreeBSD.ORG Sun Mar 8 07:09:25 2009 Return-Path: Delivered-To: arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A476106564A for ; Sun, 8 Mar 2009 07:09:25 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id E0FB68FC14 for ; Sun, 8 Mar 2009 07:09:24 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id n2879O8d018478; Sun, 8 Mar 2009 03:09:24 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n2879OdP018477; Sun, 8 Mar 2009 03:09:24 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Sun, 8 Mar 2009 03:09:24 -0400 From: David Schultz To: Sam Leffler Message-ID: <20090308070924.GA39236@zim.MIT.EDU> Mail-Followup-To: Sam Leffler , arch@FreeBSD.ORG References: <20090307103138.GA34456@zim.MIT.EDU> <49B2B139.6010104@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49B2B139.6010104@freebsd.org> Cc: arch@FreeBSD.ORG Subject: Re: C99 inlines X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 07:09:25 -0000 On Sat, Mar 07, 2009, Sam Leffler wrote: > David Schultz wrote: > >I'd like the gcc in our tree to use the C99 semantics instead of GNU > >semantics for inline functions in C99 and GNU99 mode. The following > >patch implements this behavior. It is based on a snapshot of the gcc > >4.3 branch from March 2007, prior to the GPLv3 switch. > > > > Why? I can imagine it improving portability to other toolchains like > LLVM, ICC, etc. > > I'm not opposed but seems like you should be clear. My main motivation is that currently there's no easy way to use non-static inline functions that works with both gcc and other compilers. Furthermore, even GNU wants to move to using the C99 semantics by default. Once that happens, continuing to be dependent upon the old GNU inline semantics is likely to cause porting headaches. From owner-freebsd-arch@FreeBSD.ORG Mon Mar 9 13:28:03 2009 Return-Path: Delivered-To: arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E31B106564A for ; Mon, 9 Mar 2009 13:28:03 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwqsrv02p.mx.bigpond.com (nschwqsrv02p.mx.bigpond.com [61.9.189.234]) by mx1.freebsd.org (Postfix) with ESMTP id EFB1D8FC1A for ; Mon, 9 Mar 2009 13:28:02 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwotgx02p.mx.bigpond.com ([124.188.162.219]) by nschwmtas02p.mx.bigpond.com with ESMTP id <20090309105554.EDQS22514.nschwmtas02p.mx.bigpond.com@nschwotgx02p.mx.bigpond.com> for ; Mon, 9 Mar 2009 10:55:54 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nschwotgx02p.mx.bigpond.com with ESMTP id <20090309105552.DCIH11603.nschwotgx02p.mx.bigpond.com@areilly.bpa.nu> for ; Mon, 9 Mar 2009 10:55:52 +0000 Received: (qmail 3954 invoked by uid 501); 9 Mar 2009 10:55:41 -0000 Date: Mon, 9 Mar 2009 21:55:41 +1100 From: Andrew Reilly To: Sam Leffler , arch@FreeBSD.ORG Message-ID: <20090309105541.GA2464@duncan.reilly.home> References: <20090307103138.GA34456@zim.MIT.EDU> <49B2B139.6010104@freebsd.org> <20090308070924.GA39236@zim.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090308070924.GA39236@zim.MIT.EDU> User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150204.49B4F5B9.0030:SCFSTAT4301531,ss=1,fgs=0 Cc: Subject: Re: C99 inlines X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 13:28:04 -0000 On Sun, Mar 08, 2009 at 03:09:24AM -0400, David Schultz wrote: > My main motivation is that currently there's no easy way to use > non-static inline functions that works with both gcc and other > compilers. Please pardon my ignorance: what *is* non-static inline behaviour? I've only ever used static inlines myself: they're the only sort that make sense (to me), in the world of standard C static compilation and linkage. What happens elsewhen? Does the compiler generate a "real" function with an exportable name that can be linked-to? Why would you want to do that, when that's what perfectly ordinary functions do? I can't imagine an extern inline meaning anything useful unless one can do LLVM-style link-time optimization. Is that on the cards? > Furthermore, even GNU wants to move to using the C99 > semantics by default. Once that happens, continuing to be > dependent upon the old GNU inline semantics is likely to cause > porting headaches. Well, we don't want to be depending on non-standard semantics, if we can help it. Sure. Are we? Where? Cheers, -- Andrew From owner-freebsd-arch@FreeBSD.ORG Mon Mar 9 13:58:20 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C26541065676; Mon, 9 Mar 2009 13:58:20 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from viefep15-int.chello.at (viefep15-int.chello.at [62.179.121.35]) by mx1.freebsd.org (Postfix) with ESMTP id CCEE18FC14; Mon, 9 Mar 2009 13:58:19 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from edge01.upc.biz ([192.168.13.236]) by viefep12-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090309134105.YBOH12380.viefep12-int.chello.at@edge01.upc.biz>; Mon, 9 Mar 2009 14:41:05 +0100 Received: from lizard.fafoe.narf.at ([213.47.85.26]) by edge01.upc.biz with edge id R1h41b00F0a5KZh011h58D; Mon, 09 Mar 2009 14:41:05 +0100 X-SourceIP: 213.47.85.26 Received: by lizard.fafoe.narf.at (Postfix, from userid 1001) id 81D95BC24; Mon, 9 Mar 2009 14:40:42 +0100 (CET) Date: Mon, 9 Mar 2009 14:40:42 +0100 From: Stefan Farfeleder To: Andrew Reilly Message-ID: <20090309134041.GA23152@lizard.fafoe.narf.at> References: <20090307103138.GA34456@zim.MIT.EDU> <49B2B139.6010104@freebsd.org> <20090308070924.GA39236@zim.MIT.EDU> <20090309105541.GA2464@duncan.reilly.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090309105541.GA2464@duncan.reilly.home> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: arch@FreeBSD.ORG, Sam Leffler Subject: Re: C99 inlines X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 13:58:21 -0000 On Mon, Mar 09, 2009 at 09:55:41PM +1100, Andrew Reilly wrote: > On Sun, Mar 08, 2009 at 03:09:24AM -0400, David Schultz wrote: > > My main motivation is that currently there's no easy way to use > > non-static inline functions that works with both gcc and other > > compilers. > > Please pardon my ignorance: what *is* non-static inline > behaviour? I've only ever used static inlines myself: they're > the only sort that make sense (to me), in the world of standard > C static compilation and linkage. What happens elsewhen? Does > the compiler generate a "real" function with an exportable name > that can be linked-to? Why would you want to do that, when > that's what perfectly ordinary functions do? I can't imagine an > extern inline meaning anything useful unless one can do > LLVM-style link-time optimization. Is that on the cards? With static inline functions you end up with a copy in each object file where the compiler decided to not inline at least one call, with an inline function with external linkage all these copies are coalesced to a single one. From owner-freebsd-arch@FreeBSD.ORG Mon Mar 9 17:15:01 2009 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AD351065688 for ; Mon, 9 Mar 2009 17:15:01 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4FA678FC17 for ; Mon, 9 Mar 2009 17:15:01 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n29HF1Nv045186 for ; Mon, 9 Mar 2009 17:15:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n29HF0o3045179 for freebsd-arch@FreeBSD.org; Mon, 9 Mar 2009 17:15:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 9 Mar 2009 17:15:00 GMT Message-Id: <200903091715.n29HF0o3045179@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arch@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 17:15:02 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From owner-freebsd-arch@FreeBSD.ORG Tue Mar 10 17:02:22 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FB49106564A; Tue, 10 Mar 2009 17:02:22 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id 9D58D8FC14; Tue, 10 Mar 2009 17:02:21 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 10 Mar 2009 10:03:09 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.14.3/8.14.1) with ESMTP id n2AH2LcJ086299; Tue, 10 Mar 2009 10:02:21 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.3/8.14.3/Submit) id n2AH2LJK086298; Tue, 10 Mar 2009 10:02:21 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200903101702.n2AH2LJK086298@ambrisko.com> In-Reply-To: To: brooks@freebsd.org Date: Tue, 10 Mar 2009 10:02:21 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: arch@freebsd.org Subject: Re: rtld enhancement to add osversion sub-directory search X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 17:02:22 -0000 Doug Ambrisko writes: | Brooks Davis writes: | | On Fri, Feb 13, 2009 at 01:08:56PM -0800, Doug Ambrisko wrote: | | > David Schultz writes: | | > | On Thu, Feb 12, 2009, Doug Ambrisko wrote: | | > | > Kostik Belousov writes: | | > | > | There is a popular feature, unfortunately, not supported by FreeBSD | | > | > | ld.so, called Dynamic String Tokens, see | | > | > | http://docs.sun.com/app/docs/doc/817-1984/appendixc-4?l=en&a=view | | > | > | | | > | > | I have almost abandoned patch that adds support for $ORIGIN, $OSREL, | | > | > | $OSNAME, and $PLATFORM. Quite amazingly, it merged with today CURRENT | | > | > | without serious conflicts. | | > | > | http://people.freebsd.org/~kib/misc/rtld_locks.4.patch | | > | > | | > | > That is an interesting feature, however, it almost seems backwards for | | > | > me if I understand it correctly. I need old binaries to find the library | | > | > it was built with and not new ones based on the base OS. The plus that | | > | > I see with their feature is for a library that has been optimized for a | | > | > specific type of CPU etc. | | > | | | > | The Solaris rtld features are very useful when you want to | | > | export a volume with a bunch of apps over NFS, and the clients are | | > | running different releases or different architectures. It can | | > | probably also solve your problem if you bother to place different | | > | library versions in different directories and set your library | | > | path appropriately. | | > | | > Unless I missed something it seems to be an inverse feature to | | > what I want since it expands based on the current kernel's | | > uname type results. I need it to expand based on the original OS | | > that it was built on. I'll have to see if my Solaris box at work | | > has this feature or not. I can't change LD_LIBRARY_PATH etc. | | > type things. Doing ldconfig -m of various things doesn't help | | > since that can find the wrong one. My idea was to do something | | > like what happens for 32bit on 64bit and Linux on FreeBSD in that | | > it looks at osversion specific places then the standard. | | | | While I commented on the Dynamic String Tokens and think it might be | | useful, that's a distraction for your proposal. I think you proposal | | sounds useful as well. If it was in 7 by the time I upgrade my cluster | | from 6, I'd probably use it to ease the transition. | | Since my scheme seems useful, then I'll proceed to clean up my patch | some more then send it out for people to play with and comment on. Below is the patch, got tied up with other issues. It include the LD32_ then LD_ search as well. I use LD_MAP_UNKNOWN_OS_VERSION to set the default version if the .note version is missing. Once this gets into shape then I'll update the man page. Thanks for looking, Doug A. Index: rtld.c =================================================================== RCS file: /cvs/src/libexec/rtld-elf/rtld.c,v retrieving revision 1.128 diff -u -p -w -r1.128 rtld.c --- rtld.c 10 Oct 2008 00:16:32 -0000 1.128 +++ rtld.c 24 Feb 2009 00:05:10 -0000 @@ -103,7 +103,7 @@ static bool is_exported(const Elf_Sym *) static void linkmap_add(Obj_Entry *); static void linkmap_delete(Obj_Entry *); static int load_needed_objects(Obj_Entry *); -static int load_preload_objects(void); +static int load_preload_objects(char *); static Obj_Entry *load_object(const char *, const Obj_Entry *); static Obj_Entry *obj_from_addr(const void *); static void objlist_call_fini(Objlist *, int *lockstate); @@ -157,6 +157,11 @@ static char *ld_debug; /* Environment v static char *ld_library_path; /* Environment variable for search path */ static char *ld_preload; /* Environment variable for libraries to load first */ +#ifdef COMPAT_32BIT +static char *ld32_library_path; /* Environment variable for search path */ +static char *ld32_preload; /* Environment variable for libraries to + load first */ +#endif static char *ld_tracing; /* Called from ldd to print libs */ static char *ld_utrace; /* Use utrace() to log events. */ static Obj_Entry *obj_list; /* Head of linked list of shared objects */ @@ -284,6 +289,15 @@ ld_utrace_log(int event, void *handle, v } /* + * OS Versions to try. Will iterate through the string list looking for + * sub-directories with that name. When a NULL is found it will stop + * iterating through the list. To search the standard location a "" + * version needs to be listed before the NULL. + */ +static char *os_version_try[] = {NULL, NULL, NULL}; +#define OS_VERSION_LEN 10 /* max ascii size of int */ +#define OS_VERSION_MAJOR 100000 /* divisor to get os major */ +/* * Main entry point for dynamic linking. The first argument is the * stack pointer. The stack is expected to be laid out as described * in the SVR4 ABI specification, Intel 386 Processor Supplement. @@ -363,6 +377,13 @@ _rtld(Elf_Addr *sp, func_ptr_type *exit_ unsetenv(LD_ "LIBRARY_PATH"); unsetenv(LD_ "LIBMAP_DISABLE"); unsetenv(LD_ "DEBUG"); +#ifdef COMPAT_32BIT + unsetenv(LD_32_ "PRELOAD"); + unsetenv(LD_32_ "LIBMAP"); + unsetenv(LD_32_ "LIBRARY_PATH"); + unsetenv(LD_32_ "LIBMAP_DISABLE"); + unsetenv(LD_32_ "DEBUG"); +#endif } ld_debug = getenv(LD_ "DEBUG"); libmap_disable = getenv(LD_ "LIBMAP_DISABLE") != NULL; @@ -373,6 +394,23 @@ _rtld(Elf_Addr *sp, func_ptr_type *exit_ (ld_library_path != NULL) || (ld_preload != NULL); ld_tracing = getenv(LD_ "TRACE_LOADED_OBJECTS"); ld_utrace = getenv(LD_ "UTRACE"); +#ifdef COMPAT_32BIT + ld_debug = getenv(LD_32_ "DEBUG"); + libmap_disable = getenv(LD_32_ "LIBMAP_DISABLE") != NULL; + libmap_override = getenv(LD_32_ "LIBMAP"); + ld32_library_path = getenv(LD_32_ "LIBRARY_PATH"); + ld32_preload = getenv(LD_32_ "PRELOAD"); + if (ld32_library_path == NULL) + ld32_library_path = ld_library_path; + if (ld32_preload == NULL) + ld32_preload = ld_preload; + dangerous_ld_env = libmap_disable || (libmap_override != NULL) || + (ld32_library_path != NULL) || (ld32_preload != NULL) || + (ld_library_path != NULL) || (ld_preload != NULL); + dangerous_ld_env = 0; + ld_tracing = getenv(LD_32_ "TRACE_LOADED_OBJECTS"); + ld_utrace = getenv(LD_32_ "UTRACE"); +#endif if (ld_debug != NULL && *ld_debug != '\0') debug = 1; @@ -409,6 +447,25 @@ _rtld(Elf_Addr *sp, func_ptr_type *exit_ if ((obj_main = digest_phdr(phdr, phnum, entry, argv0)) == NULL) die(); } + if (obj_main->ndesc != NULL && strcmp(obj_main->ndesc, "FreeBSD") == 0) { + os_version_try[0] = xmalloc(OS_VERSION_LEN); + snprintf(os_version_try[0], OS_VERSION_LEN, "%d", obj_main->nver); + os_version_try[1] = xmalloc(OS_VERSION_LEN); + snprintf(os_version_try[1], OS_VERSION_LEN, "%d", obj_main->nver + / OS_VERSION_MAJOR); + os_version_try[2] = ""; + } else { + /* Deal with FreeBSD 6 binaries that are missing version */ + os_version_try[0] = getenv(LD_ "MAP_UNKNOWN_OS_VERSION"); + if (os_version_try[0] == NULL) { + os_version_try[0] = ""; + } else { + os_version_try[1] = xmalloc(OS_VERSION_LEN); + snprintf(os_version_try[1], OS_VERSION_LEN, "%d", + atoi(os_version_try[0]) / OS_VERSION_MAJOR); + os_version_try[2] = ""; + } + } obj_main->path = xstrdup(argv0); obj_main->mainprog = true; @@ -447,8 +504,14 @@ _rtld(Elf_Addr *sp, func_ptr_type *exit_ libmap_disable = (bool)lm_init(libmap_override); dbg("loading LD_PRELOAD libraries"); - if (load_preload_objects() == -1) +#ifdef COMPAT_32BIT + if (load_preload_objects(ld32_preload) == -1) + if (load_preload_objects(ld_preload) == -1) die(); +#else + if (load_preload_objects(ld_preload) == -1) + die(); +#endif preload_tail = obj_tail; dbg("loading needed objects"); @@ -861,12 +924,24 @@ digest_phdr(const Elf_Phdr *phdr, int ph Obj_Entry *obj; const Elf_Phdr *phlimit = phdr + phnum; const Elf_Phdr *ph; + const Elf_Note *nh; int nsegs = 0; obj = obj_new(); for (ph = phdr; ph < phlimit; ph++) { switch (ph->p_type) { + case PT_NOTE: + nh = ((const Elf_Note *)(const Elf_Phdr *)ph->p_vaddr); + if (nh->n_type == NT_PRSTATUS) { + obj->ndesc = &((char *)((const Elf_Phdr *)ph->p_vaddr)) + [sizeof(nh->n_namesz) + sizeof(nh->n_descsz) + sizeof(nh->n_type)]; + obj->nver = *(u_int32_t *)(&((const char *)((const Elf_Phdr *)ph->p_vaddr)) + [sizeof(nh->n_namesz) + sizeof(nh->n_descsz) + sizeof(nh->n_type) + + ((const Elf_Note *)(const Elf_Phdr *)ph->p_vaddr)->n_namesz]); + } + break; + case PT_PHDR: if ((const Elf_Phdr *)ph->p_vaddr != phdr) { _rtld_error("%s: invalid PT_PHDR", path); @@ -994,6 +1069,9 @@ find_library(const char *xname, const Ob { char *pathname; char *name; + int i; + char *temp; + char new_path[PATH_MAX]; if (strchr(xname, '/') != NULL) { /* Hard coded pathname */ if (xname[0] != '/' && !trust) { @@ -1001,7 +1079,24 @@ find_library(const char *xname, const Ob xname); return NULL; } - return xstrdup(xname); + for (i = 0; os_version_try[i] != NULL; i++) { + if (os_version_try[i][0] == '\0') + temp = (char *)xname; + else { + bzero(new_path, sizeof(new_path)); + bcopy(xname, new_path, strlen(xname) + 1); + temp = rindex(new_path, '/'); + temp++; + *temp = '\0'; + strncat(new_path, os_version_try[i], sizeof(new_path)); + temp = rindex(xname, '/'); + strncat(new_path, temp, sizeof(new_path)); + temp = new_path; + } + if (access(temp, F_OK) == 0) + return xstrdup(temp); + } + return NULL; } if (libmap_disable || (refobj == NULL) || @@ -1010,6 +1105,14 @@ find_library(const char *xname, const Ob dbg(" Searching for \"%s\"", name); +#ifdef COMPAT_32BIT + if ((pathname = search_library_path(name, ld32_library_path)) != NULL || + (refobj != NULL && + (pathname = search_library_path(name, refobj->rpath)) != NULL) || + (pathname = search_library_path(name, gethints())) != NULL || + (pathname = search_library_path(name, STANDARD_LIBRARY_PATH)) != NULL) + return pathname; +#endif if ((pathname = search_library_path(name, ld_library_path)) != NULL || (refobj != NULL && (pathname = search_library_path(name, refobj->rpath)) != NULL) || @@ -1311,9 +1414,9 @@ load_needed_objects(Obj_Entry *first) } static int -load_preload_objects(void) +load_preload_objects(char *preload) { - char *p = ld_preload; + char *p = preload; static const char delim[] = " \t:;"; if (p == NULL) @@ -1326,6 +1429,7 @@ load_preload_objects(void) savech = p[len]; p[len] = '\0'; + if (find_library(p, NULL) != NULL) if (load_object(p, NULL) == NULL) return -1; /* XXX - cleanup */ p[len] = savech; @@ -1731,26 +1835,36 @@ static void * try_library_path(const char *dir, size_t dirlen, void *param) { struct try_library_args *arg; + char *version = NULL; + int temp_dirlen, i; arg = param; if (*dir == '/' || trust) { char *pathname; - if (dirlen + 1 + arg->namelen + 1 > arg->buflen) - return (NULL); - + for (i = 0; os_version_try[i] != NULL; i++) { + if (dirlen + 1 + arg->namelen + 1 + strlen(os_version_try[i]) + 1 > arg->buflen) + continue; + version = os_version_try[i]; + temp_dirlen = dirlen; pathname = arg->buffer; - strncpy(pathname, dir, dirlen); - pathname[dirlen] = '/'; - strcpy(pathname + dirlen + 1, arg->name); - + pathname[0] = '\000'; + strncpy(pathname, dir, temp_dirlen); + pathname[temp_dirlen] = '/'; + if (version[0] != '\000') { + strcpy(pathname + temp_dirlen + 1, version); + temp_dirlen += strlen(os_version_try[i]) + 1; + pathname[temp_dirlen] = '/'; + } + strcpy(pathname + temp_dirlen + 1, arg->name); dbg(" Trying \"%s\"", pathname); if (access(pathname, F_OK) == 0) { /* We found it */ - pathname = xmalloc(dirlen + 1 + arg->namelen + 1); + pathname = xmalloc(temp_dirlen + 1 + arg->namelen + 1); strcpy(pathname, arg->buffer); return (pathname); } } + } return (NULL); } @@ -2729,8 +2843,9 @@ trace_loaded_objects(Obj_Entry *obj) printf("%s:\n", obj->path); for (needed = obj->needed; needed; needed = needed->next) { if (needed->obj != NULL) { - if (needed->obj->traced && !list_containers) + if (needed->obj->traced && !list_containers) { continue; + } needed->obj->traced = true; path = needed->obj->path; } else Index: rtld.h =================================================================== RCS file: /cvs/src/libexec/rtld-elf/rtld.h,v retrieving revision 1.39 diff -u -p -w -r1.39 rtld.h --- rtld.h 4 Apr 2008 20:59:26 -0000 1.39 +++ rtld.h 24 Feb 2009 00:05:10 -0000 @@ -45,7 +45,7 @@ #define _PATH_ELF_HINTS "/var/run/ld-elf32.so.hints" /* For running 32 bit binaries */ #define STANDARD_LIBRARY_PATH "/lib32:/usr/lib32" -#define LD_ "LD_32_" +#define LD_32_ "LD_32_" #endif #ifndef STANDARD_LIBRARY_PATH @@ -223,6 +223,9 @@ typedef struct Struct_Obj_Entry { dev_t dev; /* Object's filesystem's device */ ino_t ino; /* Object's inode number */ void *priv; /* Platform-dependant */ + + char *ndesc; /* Note Description */ + u_int32_t nver; /* FreeBSD Version */ } Obj_Entry; #define RTLD_MAGIC 0xd550b87a From owner-freebsd-arch@FreeBSD.ORG Tue Mar 10 18:44:07 2009 Return-Path: Delivered-To: arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D78A10656EC; Tue, 10 Mar 2009 18:44:07 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 19CB18FC14; Tue, 10 Mar 2009 18:44:06 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id n2AIiX3V072595; Tue, 10 Mar 2009 14:44:33 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n2AIiXGV072594; Tue, 10 Mar 2009 14:44:33 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Tue, 10 Mar 2009 14:44:33 -0400 From: David Schultz To: Andrew Reilly Message-ID: <20090310184433.GA72420@zim.MIT.EDU> Mail-Followup-To: Andrew Reilly , Sam Leffler , arch@FreeBSD.ORG References: <20090307103138.GA34456@zim.MIT.EDU> <49B2B139.6010104@freebsd.org> <20090308070924.GA39236@zim.MIT.EDU> <20090309105541.GA2464@duncan.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090309105541.GA2464@duncan.reilly.home> Cc: arch@FreeBSD.ORG, Sam Leffler Subject: Re: C99 inlines X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 18:44:07 -0000 On Mon, Mar 09, 2009, Andrew Reilly wrote: > On Sun, Mar 08, 2009 at 03:09:24AM -0400, David Schultz wrote: > > My main motivation is that currently there's no easy way to use > > non-static inline functions that works with both gcc and other > > compilers. > > Please pardon my ignorance: what *is* non-static inline > behaviour? I've only ever used static inlines myself: they're > the only sort that make sense (to me), in the world of standard > C static compilation and linkage. What happens elsewhen? Does > the compiler generate a "real" function with an exportable name > that can be linked-to? Why would you want to do that, when > that's what perfectly ordinary functions do? I can't imagine an > extern inline meaning anything useful unless one can do > LLVM-style link-time optimization. Is that on the cards? > > > Furthermore, even GNU wants to move to using the C99 > > semantics by default. Once that happens, continuing to be > > dependent upon the old GNU inline semantics is likely to cause > > porting headaches. > > Well, we don't want to be depending on non-standard semantics, > if we can help it. Sure. Are we? Where? `static inline' is the easiest to use and understand, and it's the only kind where the old GNU rules and C99 agree. So if you're using `static inline', nothing changes. The relevance of non-static inlines becomes apparent if the compiler decides *not* to inline your function. With static inlines, you get a separate static definition in each object file in this case. With non-static inlines, you can arrange to have the compiler generate an external reference to a single module that defines the function. You could argue that the extra copies that `static inline' implies aren't a big deal, and I'd agree with you. So why bother getting the semantics of `inline' and `extern inline' sorted out? Here are a few reasons: - Sometimes standards require libraries to have an externally-visible version of a symbol, even if the header provides an inline definition. In this case, the compiler should pick up the external version if the function isn't inlined. - As gcc 4.3+ becomes more common in the wild, third-party apps may increasingly assume C99 semantics for inlines, and we have no control over this. - In some situations, you want the compiler to inline a function in a few cases where it matters, and use an external reference everywhere else. For example, bde@ arranged for some of the trig innards of libm to be inlined in sin() and cos() because function calls with floating point are incredibly slow on i386. But for functions like lgamma() that nobody uses, the inlining is pointless. From owner-freebsd-arch@FreeBSD.ORG Tue Mar 10 22:10:26 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 798F51065675 for ; Tue, 10 Mar 2009 22:10:26 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 2656A8FC19 for ; Tue, 10 Mar 2009 22:10:26 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n2AM9TRD036680 for ; Tue, 10 Mar 2009 16:09:30 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 10 Mar 2009 21:07:46 +0900 (JST) Message-Id: <20090310.210746.1649765883.imp@bsdimp.com> To: arch@freebsd.org From: "M. Warner Losh" X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Tue_Mar_10_21_07_46_2009_884)--" Content-Transfer-Encoding: 7bit Cc: Subject: Final sanity pass: xdev X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 22:10:27 -0000 ----Next_Part(Tue_Mar_10_21_07_46_2009_884)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit OK. I've had this reviewed before, and have been using variations of this patch since 6.1. However, since it has been a while, I thought I'd see if there were any objections before I committed this patch. It installs all the FreeBSD cross build tools as $(ARCH)-freebsd-$TOOL, which is what autoconf looks for. This may help cross building ports, ultimately, but it is also nice for cross compiling kernels (other changes to follow for that). To build, just say 'sudo make xdev XDEV=mips XDEV_ARCH=mips' and away you go. Note: sudo is required, since we have to install the compilers before building the libraries for the xbuild environment. Each tool chain takes up about 75-100M of space. Last call for Comments on this patch... Warner P.S. See you at AsiaBSDCon '09, right? :) ----Next_Part(Tue_Mar_10_21_07_46_2009_884)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xdev.diff" Index: Makefile =================================================================== --- Makefile (revision 189571) +++ Makefile (working copy) @@ -88,7 +88,7 @@ obj objlink regress rerelease showconfig tags toolchain update \ _worldtmp _legacy _bootstrap-tools _cleanobj _obj \ _build-tools _cross-tools _includes _libraries _depend \ - build32 distribute32 install32 + build32 distribute32 install32 xdev xdev-build xdev-install TGTS+= ${SUBDIR_TARGETS} BITGTS= files includes Index: Makefile.inc1 =================================================================== --- Makefile.inc1 (revision 189571) +++ Makefile.inc1 (working copy) @@ -1328,3 +1328,89 @@ # showconfig: @${MAKE} -n -f bsd.own.mk -V dummy -dg1 | grep ^MK_ | sort + + +############### + +.if defined(XDEV) && defined(XDEV_ARCH) + +NOFUN=-DNO_FSCHG -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT \ + -DWITHOUT_MAN -DWITHOUT_NLS -DWITHOUT_PROFILE \ + -DWITHOUT_KERBEROS -DWITHOUT_RESCUE -DNO_WARNS + +XDDIR=${XDEV}-freebsd +XDTP=/usr/${XDDIR} +CDBENV=MAKEOBJDIRPREFIX=${MAKEOBJDIRPREFIX}/${XDDIR} \ + TARGET=${XDEV} TARGET_ARCH=${XDEV_ARCH} +CDENV= ${CDBENV} \ + _SHLIBDIRPREFIX=${XDTP} \ + TOOLS_PREFIX=${XDTP} +CD2ENV=${CDENV} \ + MACHINE=${XDEV} MACHINE_ARCH=${XDEV_ARCH} + +CDTMP= ${MAKEOBJDIRPREFIX}/${XDEV}/${.CURDIR}/tmp +CDMAKE=${CDENV} ${MAKE} ${NOFUN} +CD2MAKE=${CD2ENV} PATH=${CDTMP}/usr/bin:${XDTP}/usr/bin:${PATH} ${MAKE} ${NOFUN} +XDDESTDIR=${DESTDIR}${XDTP} + +.ORDER: xdev-build xdev-install +xdev: xdev-build xdev-install + +.ORDER: _xb-build-tools _xb-cross-tools +xdev-build: _xb-build-tools _xb-cross-tools + +_xb-build-tools: + ${_+_}cd ${.CURDIR}; \ + ${CDBENV} ${MAKE} -f Makefile.inc1 ${NOFUN} build-tools + +_xb-cross-tools: +.for _tool in \ + gnu/usr.bin/binutils \ + gnu/usr.bin/cc + ${_+_}@${ECHODIR} "===> xdev ${_tool} (obj,depend,all)"; \ + cd ${.CURDIR}/${_tool}; \ + ${CDMAKE} DIRPRFX=${_tool}/ obj; \ + ${CDMAKE} DIRPRFX=${_tool}/ depend; \ + ${CDMAKE} DIRPRFX=${_tool}/ all +.endfor + +_xi-mtree: + ${_+_}@${ECHODIR} "mtree populating ${XDDESTDIR}" + mkdir -p ${XDDESTDIR} + mtree -deU -f ${.CURDIR}/etc/mtree/BSD.root.dist \ + -p ${XDDESTDIR} >/dev/null + mtree -deU -f ${.CURDIR}/etc/mtree/BSD.usr.dist \ + -p ${XDDESTDIR}/usr >/dev/null + mtree -deU -f ${.CURDIR}/etc/mtree/BSD.include.dist \ + -p ${XDDESTDIR}/usr/include >/dev/null + +.ORDER: _xi-mtree _xi-cross-tools _xi-includes _xi-libraries _xi-links +xdev-install: _xi-mtree _xi-cross-tools _xi-includes _xi-libraries _xi-links + +_xi-cross-tools: + @echo "_xi-cross-tools" +.for _tool in \ + gnu/usr.bin/binutils \ + gnu/usr.bin/cc + ${_+_}@${ECHODIR} "===> xdev ${_tool} (install)"; \ + cd ${.CURDIR}/${_tool}; \ + ${CDMAKE} DIRPRFX=${_tool}/ install DESTDIR=${XDDESTDIR} +.endfor + +_xi-includes: + ${_+_}cd ${.CURDIR}; ${CD2MAKE} -f Makefile.inc1 par-includes \ + DESTDIR=${XDDESTDIR} + +_xi-libraries: + ${_+_}cd ${.CURDIR}; ${CD2MAKE} -f Makefile.inc1 libraries \ + DESTDIR=${XDDESTDIR} + +_xi-links: + ${_+_}cd ${XDDESTDIR}/usr/bin; \ + for i in *; do \ + ln -sf ../../${XDTP}/usr/bin/$$i \ + ../../../../usr/bin/${XDDIR}-$$i; \ + ln -sf ../../${XDTP}/usr/bin/$$i \ + ../../../../usr/bin/${XDDIR}${OSREL}-$$i; \ + done +.endif ----Next_Part(Tue_Mar_10_21_07_46_2009_884)---- From owner-freebsd-arch@FreeBSD.ORG Wed Mar 11 07:55:44 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1150106566C for ; Wed, 11 Mar 2009 07:55:44 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 9DB698FC0A for ; Wed, 11 Mar 2009 07:55:44 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (pD9E2E7B0.dip.t-dialin.net [217.226.231.176]) by redbull.bpaserver.net (Postfix) with ESMTP id ECEE42E0F8; Wed, 11 Mar 2009 08:38:27 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id EEC621B6803; Wed, 11 Mar 2009 08:38:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1236757104; bh=7PpyihgoJgJ7G92/KHQb0kJye8k3f7jwi rVAmYNpVos=; h=Message-ID:Date:From:To:Cc:Subject:References: In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=qfwdLwYKbRgSbpgy8S+TBx/EbkZwFjvprV7o4DNK08lZ5zRp2WPgzCZN/P8KISVUt air+U1x7NYP7f9NfWrnikJ4/omiKh8tzjceciecKTU8IsYHiHrAisUYkkIk7Aujr0ld U9sUpDZg3U7QYlx4v3xW8d/ScDlKsOcVV8izuw9Ovq6eo/pSl8gkpvmjzeiarWfxefP jwh8qREuECKxxW+bZAQUiyHbczZ9E9HL4yVFjCLUMxRm3AStXwLyKAwyq/iI7LChPXx Ut0cY8FHaeiZbL8LyVCT/4adRnr6sZfz1ardBceHApTWJKCXINV4prFM834ZAuQTIi7 W/bhBncAQ== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id n2B7cNWh094879; Wed, 11 Mar 2009 08:38:23 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Wed, 11 Mar 2009 08:38:23 +0100 Message-ID: <20090311083823.14600802dxfcspyo@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Wed, 11 Mar 2009 08:38:23 +0100 From: Alexander Leidinger To: "M. Warner Losh" References: <20090310.210746.1649765883.imp@bsdimp.com> In-Reply-To: <20090310.210746.1649765883.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3) / FreeBSD-8.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: ECEE42E0F8.0928D X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, ORDB-RBL, SpamAssassin (not cached, score=-14.9, required 6, BAYES_00 -15.00, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: arch@freebsd.org Subject: Re: Final sanity pass: xdev X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 07:55:45 -0000 Quoting "M. Warner Losh" (from Tue, 10 Mar 2009 21:07:46 +0900 (JST)): > OK. I've had this reviewed before, and have been using variations of > this patch since 6.1. However, since it has been a while, I thought > I'd see if there were any objections before I committed this patch. No objections, just a "What about an else case with usage instructions when XDEV and XDEV_ARCH are not defined?". Bye, Alexander. -- It's not whether you win or lose but how you played the game. -- Grantland Rice http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-arch@FreeBSD.ORG Thu Mar 12 11:21:52 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 168B41065673 for ; Thu, 12 Mar 2009 11:21:52 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 93A4C8FC1E for ; Thu, 12 Mar 2009 11:21:51 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Lhiz1-0002mO-9L for freebsd-arch@freebsd.org; Thu, 12 Mar 2009 11:21:51 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Mar 2009 11:21:51 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Mar 2009 11:21:51 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Vadim Goncharov Date: Thu, 12 Mar 2009 11:21:38 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 46 Message-ID: References: <20090301153010.GA58942@onelab2.iet.unipi.it> <49AAFD92.105@elischer.org> <8EBEEE24-6473-411D-AE3F-C4D1D3897E51@gmail.com> <20090302190157.GA33704@onelab2.iet.unipi.it> <20090306161028.GA12322@onelab2.iet.unipi.it> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Luigi Rizzo User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: Re: spliting kernel ipfw source ? (also involves sctp) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 11:21:52 -0000 Hi Luigi Rizzo! On Fri, 6 Mar 2009 17:10:28 +0100; Luigi Rizzo wrote about 'Re: spliting kernel ipfw source ? (also involves sctp)': >>>>>>>Hi, I am planning to split netinet/ip_fw2.c in a number of smaller files >>>>>>>to make it more manageable, and while i do this I would also like to >>>>>>>move the files related to ipfw2 (namely ip_fw*c) to a better place. Any >>>>>>>objection to moving them to sys/netinet/ipfw2 ? Also, I can't help >> >> [...] >> >>> To further clarify, my plan is the following: >> >>> - leave ip_fw.h and ip_dummynet.h in /sys/netinet in case >>> userland code is dependent on their location; >>> - create /sys/netinet/ipfw/ to hold the kernel .c files related to >>> ipfw and possibly dummynet (and also their private headers if any); >> >> Exactly that and nothing more? I'm currently working on extending ipfw for >> Foundation with userland interface will be changed (and I thinking about >> introducing modules), what else do you plan to do? > Generally speaking, the kernel/userland interface will remain > unchanged both at binary and source level, which means no > backward incompatible changes in the sockopt numbers and messages, > and no changes in the location and userland-visible parts of > the headers. > In practical terms, ip_fw.h might lose the definition of > struct ip_fw_args, or the prototypes for the various kernel > functions. The #ifdef _KERNEL part of ip_dummynet.h should > also go to some other file. > If you want to contact me, on the list or offline, to discuss what > you want to do or what kind of 'modules' (kernel or userland ?) are > you thinking about, i'd be more than happy to help. I do not know whether this will be polite to discuss in details while Foundation has not yet announced my work :-/ I hope they'll do it in a week or so... I could say that at least dynamic rules and userland API/ABI will go under serious incompatible changes, so any your changing headers is OK, but what do you want to change inside kernel *.c is interesting to me. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-arch@FreeBSD.ORG Thu Mar 12 12:39:34 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26613106567A for ; Thu, 12 Mar 2009 12:39:34 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id DAE4A8FC26 for ; Thu, 12 Mar 2009 12:39:33 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 63B4A73098; Thu, 12 Mar 2009 13:44:46 +0100 (CET) Date: Thu, 12 Mar 2009 13:44:46 +0100 From: Luigi Rizzo To: Vadim Goncharov Message-ID: <20090312124446.GB28491@onelab2.iet.unipi.it> References: <20090301153010.GA58942@onelab2.iet.unipi.it> <49AAFD92.105@elischer.org> <8EBEEE24-6473-411D-AE3F-C4D1D3897E51@gmail.com> <20090302190157.GA33704@onelab2.iet.unipi.it> <20090306161028.GA12322@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-arch@freebsd.org Subject: Re: spliting kernel ipfw source ? (also involves sctp) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 12:39:34 -0000 On Thu, Mar 12, 2009 at 11:21:38AM +0000, Vadim Goncharov wrote: > Hi Luigi Rizzo! ... > > In practical terms, ip_fw.h might lose the definition of > > struct ip_fw_args, or the prototypes for the various kernel > > functions. The #ifdef _KERNEL part of ip_dummynet.h should > > also go to some other file. > > > If you want to contact me, on the list or offline, to discuss what > > you want to do or what kind of 'modules' (kernel or userland ?) are > > you thinking about, i'd be more than happy to help. > > I do not know whether this will be polite to discuss in details while > Foundation has not yet announced my work :-/ I hope they'll do it in a week I see no reason to keep things secret. In fact, I'd try to be as open as possible as there is plenty of people on this list with with a lot of experience on the various issues at hand, and could give you valuable feedback. > or so... I could say that at least dynamic rules and userland API/ABI will > go under serious incompatible changes, so any your changing headers is OK, > but what do you want to change inside kernel *.c is interesting to me. First of all I want to split the files because ip_fw.2 is currently too large to be effectively maintained. There are more things that should be addressed, after proper performance assessment, e.g replacing the huge switch with a table of function pointers, fixing the way information is passed up in the "ipfw show" and "pipe show" commands, replacing the custom hash table with something already in the kernel, and perhaps a better hash function. Even more work (but this is not something I plan to do) involves the locking: there is contention on the rule counters (which I am not sure if/how is handled now) and contention on the dynamic rules, which possibly might be reduced by locking on the individual buckets. cheers luigi From owner-freebsd-arch@FreeBSD.ORG Fri Mar 13 12:51:17 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3660B106568B for ; Fri, 13 Mar 2009 12:51:17 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id C98FF8FC27 for ; Fri, 13 Mar 2009 12:51:16 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id A8B551CE0D; Fri, 13 Mar 2009 13:51:15 +0100 (CET) Date: Fri, 13 Mar 2009 13:51:15 +0100 From: Ed Schouten To: "M. Warner Losh" Message-ID: <20090313125115.GU31961@hoeg.nl> References: <20090310.210746.1649765883.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="magLDk5D4XGaUXcd" Content-Disposition: inline In-Reply-To: <20090310.210746.1649765883.imp@bsdimp.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: arch@freebsd.org Subject: Re: Final sanity pass: xdev X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 12:51:17 -0000 --magLDk5D4XGaUXcd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Warner, The last couple of days/weeks I've been working a lot with LLVM+Clang. I'm currently writing some BSD makefiles to see how hard it is to add Clang to our base system, as a proof of concept. A nice thing about Clang is that it seems to be very easy to compile in multiple backends into the same Clang binary. If we ever switch to Clang in the base system (who knows), it would be interesting to see whether it's useful to just compile in all backends by default. Anyway, I took a quick look at the xdev patch and it looks okay. :-) --=20 Ed Schouten WWW: http://80386.nl/ --magLDk5D4XGaUXcd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkm6VsMACgkQ52SDGA2eCwVcPgCfefF8EZAYwxv2a/UGe9vSdFVu pYcAn2KS3kqrcPVaCIAsMPctOrHvqo3L =ClTL -----END PGP SIGNATURE----- --magLDk5D4XGaUXcd-- From owner-freebsd-arch@FreeBSD.ORG Fri Mar 13 15:05:08 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF27B1065686 for ; Fri, 13 Mar 2009 15:05:08 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 55B3D8FC1C for ; Fri, 13 Mar 2009 15:05:08 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n2DF0GUr008799; Fri, 13 Mar 2009 09:00:17 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 13 Mar 2009 09:00:38 -0600 (MDT) Message-Id: <20090313.090038.-890725739.imp@bsdimp.com> To: ed@80386.nl From: "M. Warner Losh" In-Reply-To: <20090313125115.GU31961@hoeg.nl> References: <20090310.210746.1649765883.imp@bsdimp.com> <20090313125115.GU31961@hoeg.nl> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: Final sanity pass: xdev X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 15:05:09 -0000 In message: <20090313125115.GU31961@hoeg.nl> Ed Schouten writes: : Hi Warner, : : The last couple of days/weeks I've been working a lot with LLVM+Clang. : I'm currently writing some BSD makefiles to see how hard it is to add : Clang to our base system, as a proof of concept. : : A nice thing about Clang is that it seems to be very easy to compile in : multiple backends into the same Clang binary. If we ever switch to Clang : in the base system (who knows), it would be interesting to see whether : it's useful to just compile in all backends by default. : : Anyway, I took a quick look at the xdev patch and it looks okay. :-) Woot! Please let me know if it causes problems. Warner From owner-freebsd-arch@FreeBSD.ORG Sat Mar 14 18:25:07 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9888310656C6 for ; Sat, 14 Mar 2009 18:25:07 +0000 (UTC) (envelope-from jhein@timing.com) Received: from Daffy.timing.com (mx2.timing.com [206.168.13.218]) by mx1.freebsd.org (Postfix) with ESMTP id 5F6078FC22 for ; Sat, 14 Mar 2009 18:25:07 +0000 (UTC) (envelope-from jhein@timing.com) Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by Daffy.timing.com (8.13.1/8.13.1) with ESMTP id n2EHr6d5082402 for ; Sat, 14 Mar 2009 11:53:07 -0600 (MDT) (envelope-from jhein@timing.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.14.3/8.14.3) with ESMTP id n2EHcvBm067570; Sat, 14 Mar 2009 11:38:57 -0600 (MDT) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.14.3/8.14.3/Submit) id n2EHctM4067566; Sat, 14 Mar 2009 11:38:55 -0600 (MDT) (envelope-from jhein) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18875.60334.947446.966085@gromit.timing.com> Date: Sat, 14 Mar 2009 11:38:54 -0600 From: John Hein To: "M. Warner Losh" In-Reply-To: <20090313.090038.-890725739.imp@bsdimp.com> References: <20090310.210746.1649765883.imp@bsdimp.com> <20090313125115.GU31961@hoeg.nl> <20090313.090038.-890725739.imp@bsdimp.com> X-Mailer: VM 7.19 under Emacs 22.3.1 X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on Daffy.timing.com X-Virus-Status: Clean Cc: ed@80386.nl, arch@freebsd.org Subject: Re: Final sanity pass: xdev X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2009 18:25:09 -0000 M. Warner Losh wrote at 09:00 -0600 on Mar 13, 2009: > In message: <20090313125115.GU31961@hoeg.nl> > Ed Schouten writes: > : Hi Warner, > : > : The last couple of days/weeks I've been working a lot with LLVM+Clang. > : I'm currently writing some BSD makefiles to see how hard it is to add > : Clang to our base system, as a proof of concept. > : > : A nice thing about Clang is that it seems to be very easy to compile in > : multiple backends into the same Clang binary. If we ever switch to Clang > : in the base system (who knows), it would be interesting to see whether > : it's useful to just compile in all backends by default. > : > : Anyway, I took a quick look at the xdev patch and it looks okay. :-) > > Woot! Please let me know if it causes problems. I meant to mention this earlier - OSREL (referenced in the _xi-links: target) is not defined. So ports looking for arm-freebsd8.0-cc (for instance) won't find it. An earlier patch of yours had: .if !defined(OSREL) OSREL!= uname -r | sed -e 's/[-(].*//' .endif But the latest (and the one committed) does not. From owner-freebsd-arch@FreeBSD.ORG Sat Mar 14 23:11:01 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E66F106566C for ; Sat, 14 Mar 2009 23:11:01 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 4F8008FC20 for ; Sat, 14 Mar 2009 23:11:01 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n2EN7mFh041553; Sat, 14 Mar 2009 17:07:49 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 15 Mar 2009 08:08:14 +0900 (JST) Message-Id: <20090315.080814.669286040.imp@bsdimp.com> To: jhein@timing.com From: "M. Warner Losh" In-Reply-To: <18875.60334.947446.966085@gromit.timing.com> References: <20090313125115.GU31961@hoeg.nl> <20090313.090038.-890725739.imp@bsdimp.com> <18875.60334.947446.966085@gromit.timing.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ed@80386.nl, arch@freebsd.org Subject: Re: Final sanity pass: xdev X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2009 23:11:01 -0000 In message: <18875.60334.947446.966085@gromit.timing.com> John Hein writes: : M. Warner Losh wrote at 09:00 -0600 on Mar 13, 2009: : > In message: <20090313125115.GU31961@hoeg.nl> : > Ed Schouten writes: : > : Hi Warner, : > : : > : The last couple of days/weeks I've been working a lot with LLVM+Clang. : > : I'm currently writing some BSD makefiles to see how hard it is to add : > : Clang to our base system, as a proof of concept. : > : : > : A nice thing about Clang is that it seems to be very easy to compile in : > : multiple backends into the same Clang binary. If we ever switch to Clang : > : in the base system (who knows), it would be interesting to see whether : > : it's useful to just compile in all backends by default. : > : : > : Anyway, I took a quick look at the xdev patch and it looks okay. :-) : > : > Woot! Please let me know if it causes problems. : : I meant to mention this earlier - OSREL (referenced in the _xi-links: : target) is not defined. So ports looking for arm-freebsd8.0-cc (for : instance) won't find it. : : : An earlier patch of yours had: : : .if !defined(OSREL) : OSREL!= uname -r | sed -e 's/[-(].*//' : .endif : : But the latest (and the one committed) does not. You are right... Dang. I must have comitted the wrong thing... Warner