New tools and 4.6.99.3

[Steven Johnson]

Joel Sherrill wrote:

> I've been out of pocket between the class and a death in my faimly
> last week

I'm sorry to hear about that.

> 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.

This is no problem.  See attached patch which does it with a separate file.

>
> libchip comment below

[snip]

>
> 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.

I understand.  The issue arises for me because i'm using the bare bsp. 
And it seemed that libchip didnt like to build (or at least parts of
libchip) with the bare bsp, because of deficiencies in bsp.h for the
bare bsp, which only effect libchip.  Because of the value of the bare
bsp for me (I can have all my bsp stuff in my application for my wierd
hardware) outweighed the need for libchip (because i dont use it)  I
just turned to a "turn off libchip" approach to get past it.  Im doing
that now, with a patch to the build tree, that i'm happy to live with to
get around the problem, so i suppose this could be better read as a
report on a failure to build "libchip" with the bare bsp for a MPC860
CPU target.  Do you want me to revert my patch and rebuild, so i can
post the actual error that occurs?

Steven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtems-4.6.99.3-mbuf-allocate-customise2.patch
Type: text/x-patch
Size: 4649 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20060502/15aebbf8/attachment.bin>