New tools and 4.6.99.3

[Steven Johnson]

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?
>  
>
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtems-4.6.99.3-mbuf-allocate-customise.patch
Type: text/x-patch
Size: 2479 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20060427/ade56801/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtems-4.6.99.3-nolibchip.patch
Type: text/x-patch
Size: 2816 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20060427/ade56801/attachment-0003.bin>