lwIP - A Lightweight TCP/IP stack - Patches: patch #6822, Patch places memory pools in...
You are not allowed to post comments on this tracker with your current authentication level.
patch #6822: Patch places memory pools in separate arrays
Submitter: | Bill Auerbach <billauerbach> | ||
Submitted: | Fri 01 May 2009 01:30:35 PM UTC | ||
Category: | None | Priority: | 5 - Normal |
Status: | Done | Privacy: | Public |
Assigned to: | goldsimon | Open/Closed: | Closed |
Planned Release: | None |
Jump to the original submission
Sun 10 Jan 2010 01:14:05 PM UTC, comment #16: |
Simon Goldschmidt <goldsimon> |
Mon 02 Nov 2009 02:08:19 PM UTC, comment #15: I'm pretty sure we do structure packing that way on systems that use "#pragma pack"
|
Kieran Mansley <kieranm> |
Mon 02 Nov 2009 01:49:13 PM UTC, comment #14: Kieran, the point I'm trying to make is that if a compiler requires a #pragma to change a declaration's section, a #pragma can't be generated from a macro. |
Bill Auerbach <billauerbach> |
Mon 02 Nov 2009 09:06:47 AM UTC, comment #13: Fair enough, so make the MEM_ONCHIP macro more complex, so that it can control the entire declaration. I meant my example to illustrate where in the source the different bits of code should go, rather than the right code to use. |
Kieran Mansley <kieranm> |
Fri 30 Oct 2009 05:49:01 PM UTC, comment #12: Kieran, that's fine for GCC and other compilers that modify a function declaration but it will not work to inject a #pragma if that's what a compiler requires. I think that someone developing with lwIP to the point of having a reason to move pools probably can figure out to do it differently than you prescribe. |
Bill Auerbach <billauerbach> |
Fri 30 Oct 2009 04:14:38 PM UTC, comment #11: Seems like I posted a bit of code about
|
Iordan Neshev <iordan_neshev> |
Fri 30 Oct 2009 03:50:31 PM UTC, comment #10: My view is that cc.h should have the code that defines how to place these bits in different areas. lwipopts should select which one of these definitions to use.
|
Kieran Mansley <kieranm> |
Fri 30 Oct 2009 12:52:08 PM UTC, comment #9: Simon, it doesn't matter I guess. I thought cc.h is for platform/compiler specific things, right? lwipopts.h is getting really big too, but I can see the advantage to keeping them together. Or add a comment "Add to cc.h the compiler dependent statements to move the pool arrays to new sections".
|
Bill Auerbach <billauerbach> |
Fri 30 Oct 2009 12:41:29 PM UTC, comment #8: Iordan, I didn't move the discussion - this patch started as per the subject originally by me to move memory pools to new sections. I wasn't bringing up moving the heap to a new section - isn't this a different patch with a different goal? |
Bill Auerbach <billauerbach> |
Fri 30 Oct 2009 11:19:14 AM UTC, comment #7: This post would go to bug #26133, but Bill decided to
#ifndef HEAP_SECT_PRE
#ifndef HEAP_SECT_POST
|
Iordan Neshev <iordan_neshev> |
Thu 29 Oct 2009 10:03:11 PM UTC, comment #6: Oh, you mean you would place the extern definitions like the following into cc.h?
|
Simon Goldschmidt <goldsimon> |
Thu 29 Oct 2009 09:50:00 PM UTC, comment #5: I see. Yes, I thought you meant how (since you said how :-) ) more than where. Heh, I did find it a bit odd for you to ask that since I knew you knew GCC and probably the _attribute_ thing too.
|
Bill Auerbach <billauerbach> |
Thu 29 Oct 2009 09:40:59 PM UTC, comment #4: Ehrm, I think I might not have made it too clear what I wanted to know... ;-)
|
Simon Goldschmidt <goldsimon> |
Thu 29 Oct 2009 08:33:25 PM UTC, comment #3: Correction on saving RAM.
|
Bill Auerbach <billauerbach> |
Thu 29 Oct 2009 08:25:39 PM UTC, comment #2: Sure, rename things as you see fit. I had to do this for a project using GCC so is shown here for GCC. It would apply to several platforms and any others that use an extern or #pragma to move memory. It works well - I've finished one product where I moved 4 pools.
|
Bill Auerbach <billauerbach> |
Thu 29 Oct 2009 08:04:16 PM UTC, comment #1: Just to make the code more readable, I'd rather name the separated pools memp_memory_*, i.e. memp_memory_UDP_PCB to stay with the current naming scheme.
|
Simon Goldschmidt <goldsimon> |
Fri 01 May 2009 01:30:35 PM UTC, original submission:
Re: https://savannah.nongnu.org/bugs/?26133
|
Bill Auerbach <billauerbach> |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 4 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2010-01-10 | goldsimon | Status | None | Done | |
Assigned to | None | goldsimon | |||
Open/Closed | Open | Closed | |||
2009-05-01 | billauerbach | Attached File | - | Added memp_separate_pools.patch, #18070 |
Powered by Savane 3.13-3230.
Corresponding source code
I've checked in this patch (slightly modified: pools are named memp_memory_XXX_base, option moved to opt.h, comments changed) as it is essentially independent of how we relocate the individual pools: this patch only separates them.
After all, I think Bill's original idea (relocating the pools in cc.h) isn't that bad: it's quite difficult to do this with defines as we need one define per pool plus an automatic fallback if it isn't defined...
Closing this as done since the relocation to different sections is covered by bug #26133.