New tools and 4.6.99.3
Joel Sherrill
joel.sherrill at oarcorp.com
Mon May 1 14:27:09 UTC 2006
I've been out of pocket between the class and a death in my faimly last week
so am just beginning to dig out of an email backlog. This is the
easiest of the
issues to comment on.
Steven Johnson wrote:
>That was option #2 :)
>
>I originally thought of doing that, but it seemed a little excessive
>having a new .c file for a single function, that just wrapped a call to
>malloc. That would also mean messing with the automake stuff, which im
>far from comfortable doing. But if thats what is preferred, I dont have
>any problems changing it to be that way, ill work it up this morning and
>post an alternate patch.
>
>
RTEMS already has a lot of files and uses this technique to avoid linking in
unnecessary routines as well as to (sometimes) provide discrete points to
override and replace functionality. Look at the structure of a BSP. It
is lots
of small files which are structured to allow you to reuse pieces from
libbsp/shared, libbsp/CPU/shared, libcpu/..., or libchip.
This is a good case for a replacement file.
libchip comment below
>Steven
>
>Eric Norum wrote:
>
>
>
>>I don't see why you need to make weak references to malloc_mbuf().
>>Just placing malloc_mbuf() in its own source file would be adequate.
>> When the link editor gets to the archive library containing the
>>corresponding object file it will simply leave the file alone if it
>>does not satisfy any undefined references -- it the application has
>>already supplied malloc_mbuf() this will be the case and the linker
>>will use the application-supplied routine. If the application has
>>not supplied malloc_mbuf() the linker will see that the object file
>>defines this symbol and pull the code from the library.
>>
>>On Apr 26, 2006, at 10:56 PM, Steven Johnson wrote:
>>
>>
>>
>>>Further to my earlier post:
>>>
>>>Steven Johnson wrote:
>>>
>>>
>>>
>>>>Id also like the ability to statically allocate mbuf's (and friends) in
>>>>the network stack. I'm working on a generic way of doing this,
>>>>currently I just hack the code around to achieve what i need. If i come
>>>>up with something generic ill post it.
>>>>
>>>>
>>>>
>>>>
>>>Attached for comment is a proposal to change the malloc's of mbuf
>>>related structures into calls to malloc_mbuf which is declared weak, so
>>>the application can provide its own. In this way, the application could
>>>provide the address of pre-allocated static buffers for this data, which
>>>is what I need to do. By default if the application does not provide
>>>its own mbuf_malloc, the default is just to malloc, like it does now. I
>>>havent tested this yet (it does apply cleanly and build OK though), its
>>>just attached for comment.
>>>
>>>
>>>
>>>>LibChip:
>>>>
>>>>LibChip is pretty much useless for me, and I would prefer not to build
>>>>it. There is no option to not build LibChip, although the ./configure
>>>>system indicates it would be desirable. I agree. Currently a ATA
>>>>driver in libchip wont build for me, I think because I'm using a bare
>>>>bsp. It would be useful for me to just disable it. Any chance of this
>>>>becoming an option so i wont have to patch the source tree to remove it
>>>>from the build?
>>>>
>>>>
A lot of stuff in the tree is useless for any particular person or
application. You built the
webserver, telnetd, ftpd, fat, tarfs, pppd etc, etc and I am sure you
don't use all that.
This is a BSP aid directory. If you don't need or want it, don't
reference it in your
wrapup directory for your BSP.
It is just a BSP aid directory just like libcpu and is built for all
configurations. This helps
make sure that the infrastructure is consistent.
>>>>
>>>>
>>>Ive attached a small patch to configure and configure.ac which prevents
>>>libchip being built for "bare" bsp's in addition to "posix" bsp's. I
>>>think a better approach would be a --disable-libchip option, but this
>>>patch to ./configure.ac taxed my total ability to understand ./configure
>>>stuff, so im not in a position to even know where to start to add it.
>>>
>>>This one does what it should, but I think it could be better. At the
>>>very least I think this should be the default behavior for "bare" BSP's.
>>>
>>>Steven J
>>>diff -Naur rtems-4.6.99.3/cpukit/libnetworking/rtems/rtems_bsdnet.h
>>>rtems-4.6.99.3-mbuf-allocate-customise/cpukit/libnetworking/rtems/rtems_bsdnet.h
>>>--- rtems-4.6.99.3/cpukit/libnetworking/rtems/rtems_bsdnet.h
>>>2005-11-09 01:24:28.000000000 +1100
>>>+++
>>>rtems-4.6.99.3-mbuf-allocate-customise/cpukit/libnetworking/rtems/rtems_bsdnet.h
>>>2006-04-27 14:41:01.000000000 +1100
>>>@@ -260,4 +260,20 @@
>>> */
>>> void rtems_bsdnet_malloc_starvation(void);
>>>
>>>
>>>
>>>+/*
>>>+ * mbuf malloc interface to enable custom allocation of mbuf's
>>>+ *
>>>+ * May be declared in user code. If not, then the default is to
>>>+ * malloc.
>>>+ */
>>>+void* malloc_mbuf(size_t size, int type);
>>>+
>>>+/*
>>>+ * Possible values of the type parameter to malloc_mbuf to assist
>>>+ * in allocation of the structure.
>>>+ */
>>>+#define MBUF_MALLOC_NMBCLUSTERS (0)
>>>+#define MBUF_MALLOC_MCLREFCNT (1)
>>>+#define MBUF_MALLOC_MBUF (2)
>>>+
>>> #endif /* _RTEMS_BSDNET_H */
>>>diff -Naur rtems-4.6.99.3/cpukit/libnetworking/rtems/rtems_glue.c
>>>rtems-4.6.99.3-mbuf-allocate-customise/cpukit/libnetworking/rtems/rtems_glue.c
>>>--- rtems-4.6.99.3/cpukit/libnetworking/rtems/rtems_glue.c 2005-02-03
>>>16:35:38.000000000 +1100
>>>+++
>>>rtems-4.6.99.3-mbuf-allocate-customise/cpukit/libnetworking/rtems/rtems_glue.c
>>>2006-04-27 14:26:16.000000000 +1100
>>>@@ -138,6 +138,19 @@
>>> }
>>>
>>>
>>>
>>> /*
>>>+ * Default allocator for mbuf data. Over-ride in user code to change
>>>+ * the way mbuf's are allocated.
>>>+ */
>>>+
>>>+void* malloc_mbuf(size_t size, int type) __attribute__ ((__weak__));
>>>+
>>>+void* malloc_mbuf(size_t size, int type)
>>>+{
>>>+ return malloc(size);
>>>+}
>>>+
>>>+
>>>+/*
>>> * Do the initializations required by the BSD code
>>> */
>>> static int
>>>@@ -149,7 +162,7 @@
>>> /*
>>> * Set up mbuf cluster data strutures
>>> */
>>>- p = malloc ((nmbclusters*MCLBYTES)+MCLBYTES-1);
>>>+ p = malloc_mbuf ((nmbclusters*MCLBYTES)+MCLBYTES-1,
>>>MBUF_MALLOC_NMBCLUSTERS);
>>> if (p == NULL) {
>>> printf ("Can't get network cluster memory.\n");
>>> return -1;
>>>@@ -163,7 +176,7 @@
>>> mbstat.m_clfree++;
>>> }
>>> mbstat.m_clusters = nmbclusters;
>>>- mclrefcnt = malloc (nmbclusters);
>>>+ mclrefcnt = malloc_mbuf (nmbclusters, MBUF_MALLOC_MCLREFCNT);
>>> if (mclrefcnt == NULL) {
>>> printf ("Can't get mbuf cluster reference counts memory.\n");
>>> return -1;
>>>@@ -174,7 +187,7 @@
>>> * Set up mbuf data structures
>>> */
>>>
>>>
>>>
>>>- p = malloc(nmbuf * MSIZE + MSIZE - 1);
>>>+ p = malloc_mbuf(nmbuf * MSIZE + MSIZE - 1,MBUF_MALLOC_MBUF);
>>> p = (char *)(((unsigned int)p + MSIZE - 1) & ~(MSIZE - 1));
>>> if (p == NULL) {
>>> printf ("Can't get network memory.\n");
>>>diff -Naur rtems-4.6.99.3/c/src/configure
>>>rtems-4.6.99.3-nolibchip/c/src/configure
>>>--- rtems-4.6.99.3/c/src/configure 2006-04-19 13:57:50.000000000 +1100
>>>+++ rtems-4.6.99.3-nolibchip/c/src/configure 2006-04-27
>>>13:48:38.000000000 +1100
>>>@@ -4,8 +4,7 @@
>>> #
>>> # Report bugs to <rtems-bugs at rtems.com <mailto:rtems-bugs at rtems.com>>.
>>> #
>>>-# Copyright 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001, 2002,
>>>-# 2003, 2004 Free Software Foundation, Inc.
>>>+# Copyright (C) 2003 Free Software Foundation, Inc.
>>> # This configure script is free software; the Free Software Foundation
>>> # gives unlimited permission to copy, distribute and modify it.
>>> ## --------------------- ##
>>>@@ -981,7 +980,7 @@
>>> else
>>> echo "$as_me: WARNING: no configuration information is in
>>>$ac_dir" >&2
>>> fi
>>>- cd "$ac_popdir"
>>>+ cd $ac_popdir
>>> done
>>> fi
>>>
>>>
>>>
>>>@@ -991,8 +990,7 @@
>>> rtems-c-src configure 4.6.99.3
>>> generated by GNU Autoconf 2.59
>>>
>>>
>>>
>>>-Copyright 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001, 2002,
>>>-2003, 2004 Free Software Foundation, Inc.
>>>+Copyright (C) 2003 Free Software Foundation, Inc.
>>> This configure script is free software; the Free Software Foundation
>>> gives unlimited permission to copy, distribute and modify it.
>>> _ACEOF
>>>@@ -4904,11 +4902,12 @@
>>> fi
>>>
>>>
>>>
>>>
>>>
>>>-# The posix bsp doesn't support libchip
>>>+# The posix and bare bsp doesn't support libchip
>>> # FIXME: We should use a feature based check, here
>>>
>>>
>>>
>>>
>>>
>>>-if test "$RTEMS_BSP_FAMILY" != "posix"; then
>>>+if test "$RTEMS_BSP_FAMILY" != "posix" \
>>>+ && test "$RTEMS_BSP_FAMILY" != "bare"; then
>>> LIBCHIP_TRUE=
>>> LIBCHIP_FALSE='#'
>>> else
>>>@@ -5608,7 +5607,7 @@
>>> configured by $0, generated by GNU Autoconf 2.59,
>>> with options \\"`echo "$ac_configure_args" | sed
>>>'s/[\\""\`\$]/\\\\&/g'`\\"
>>>
>>>
>>>
>>>-Copyright (C) 2004 Free Software Foundation, Inc.
>>>+Copyright (C) 2003 Free Software Foundation, Inc.
>>> This config.status script is free software; the Free Software Foundation
>>> gives unlimited permission to copy, distribute and modify it."
>>> srcdir=$srcdir
>>>@@ -7063,7 +7062,7 @@
>>> { (exit 1); exit 1; }; }
>>> fi
>>>
>>>
>>>
>>>- cd "$ac_popdir"
>>>+ cd $ac_popdir
>>> done
>>> fi
>>>
>>>
>>>
>>>diff -Naur rtems-4.6.99.3/c/src/configure.ac
>>>rtems-4.6.99.3-nolibchip/c/src/configure.ac
>>>--- rtems-4.6.99.3/c/src/configure.ac 2005-11-20 19:07:55.000000000 +1100
>>>+++ rtems-4.6.99.3-nolibchip/c/src/configure.ac 2006-04-27
>>>13:48:29.000000000 +1100
>>>@@ -233,9 +233,10 @@
>>>
>>>
>>>
>>> AM_CONDITIONAL(HAS_POSIX,test "$HAS_POSIX_API" = "yes")
>>>
>>>
>>>
>>>-# The posix bsp doesn't support libchip
>>>+# The posix and bare bsp doesn't support libchip
>>> # FIXME: We should use a feature based check, here
>>>-AM_CONDITIONAL([LIBCHIP],[test "$RTEMS_BSP_FAMILY" != "posix"])
>>>+AM_CONDITIONAL([LIBCHIP],[test "$RTEMS_BSP_FAMILY" != "posix" \
>>>+ && test "$RTEMS_BSP_FAMILY" != "bare"])
>>>
>>>
>>>
>>> # The bare bsp doesn't have libbsp.a
>>> # FIXME: We should use a feature based check, here
>>>
>>>
>>--
>>
>>Eric Norum <norume at aps.anl.gov <mailto:norume at aps.anl.gov>>
>>
>>Advanced Photon Source
>>
>>Argonne National Laboratory
>>
>>(630) 252-4793
>>
>>
>>
>>
>>
>>
>
>
>
More information about the users
mailing list