lwIP - A Lightweight TCP/IP stack - Bugs: bug #26133, Processor specific porting needs...
You are not allowed to post comments on this tracker with your current authentication level.
bug #26133: Processor specific porting needs flexibility in terms of placement of various memory pools and heap
Submitter: | Zhenwei Chu <blackfin> | ||
Submitted: | Thu 09 Apr 2009 02:03:28 PM UTC | ||
Category: | None | Severity: | 3 - Normal |
Item Group: | Change Request | Status: | Fixed |
Privacy: | Public | Assigned to: | goldsimon |
Open/Closed: | Closed | Planned Release: | None |
lwIP version: | 1.3.0 |
Jump to the original submission
Wed 13 Jan 2010 01:12:09 PM UTC, comment #15: |
Simon Goldschmidt <goldsimon> |
Tue 12 Jan 2010 08:21:10 PM UTC, comment #14: Sorry that I didn't understand that from comment #10. I don't really care how it's done as long as it is supported - I require it in one of my lwIP-based projects. |
Bill Auerbach <billauerbach> |
Tue 12 Jan 2010 08:15:11 PM UTC, comment #13: The per-compiler specific stuff would be in cc.h, not lwipopt.h - that would just select where you wanted things to be by selecting one of the macros defined in cc.h - but I'm happy to go with the easy way for now as you suggest.
|
Kieran Mansley <kieranm> |
Tue 12 Jan 2010 07:45:09 PM UTC, comment #12: Comment 6822/#10 also means adding compiler and target specific items to lwipopts.h. Do you really want to do that? lwipopts now enables, disables, turns on or turns off different features or modes. AFAIK there are no compiler or platform specific settings there. |
Bill Auerbach <billauerbach> |
Tue 12 Jan 2010 06:36:12 PM UTC, comment #11: Me too, the only problem is that would result in 15 (or how many pools do we have currently) 2 (_PRE and _POST to satisfy all compilers) defines in lwipopts.h. Plus compilers using pragmas would need special include handling (as for packed structs), only with 2 files (pre and post) *for each pool.
|
Simon Goldschmidt <goldsimon> |
Tue 12 Jan 2010 04:07:48 PM UTC, comment #10: I still like the approach outlined in patch #6822 comment #10: https://savannah.nongnu.org/patch/?6822#comment10 best but happy to go with this for now and see how we get on.
|
Kieran Mansley <kieranm> |
Mon 11 Jan 2010 06:16:32 PM UTC, comment #9: Kieran and Zhenwei Chu, is that OK with you? It's not the cleanest approach, but it doesn't clutter our sources with that much ifdefs or defines. |
Simon Goldschmidt <goldsimon> |
Mon 11 Jan 2010 01:52:54 PM UTC, comment #8:
|
Bill Auerbach <billauerbach> |
Sun 10 Jan 2010 01:20:51 PM UTC, comment #7: As I already said in patch #6822: I think Bill's idea to include prototype of the heap- or pool-variable definition in cc.h (including the appropriate _attribute_ or pragme to relocate them) is good enough plus it keeps us from having _PRE and _POST defines everywhere.
|
Simon Goldschmidt <goldsimon> |
Thu 29 Oct 2009 07:11:24 PM UTC, comment #6: |
Bill Auerbach <billauerbach> |
Thu 29 Oct 2009 06:03:02 PM UTC, comment #5: Idea from Ioardan Neshev on lwip-devel (29-10-2009): Add define for linker section to definition of 'ram_heap' (we need a _PRE and _POST define here for compiler compatibility reasons, see dns.c:local_hostlist_static).
|
Simon Goldschmidt <goldsimon> |
Wed 15 Apr 2009 09:06:27 PM UTC, comment #4:
|
Srinivas Gollakota <gollakota> |
Thu 09 Apr 2009 04:39:39 PM UTC, comment #3: I can provide a patch that places each pool in it's own static array. By preceding the additions with extern declaration one can move them to different linker segments. One or more pools can be moved. I got a big increase moving what I could to onchip memory.
|
Bill Auerbach <billauerbach> |
Thu 09 Apr 2009 03:35:13 PM UTC, comment #2: I use this kind of trick to allocate the pool on an external SDRAM memory. This is prefered to keep internal RAM usage low.
|
Clément DAVID <davidcl> |
Thu 09 Apr 2009 02:43:07 PM UTC, comment #1: Can you explain how this should be used? I presume porters of lwIP will have to allocate an area of memory and poke it into ADI_TOOLS_memp_ptr or something. It's not clear what advantage this brings, and would by the look of it break the existing ports.
|
Kieran Mansley <kieranm> |
Thu 09 Apr 2009 02:03:28 PM UTC, original submission:
Protecting them with simple macro will give them a chance to declare/define at the upper level so lwip code changes as below
|
Zhenwei Chu <blackfin> |
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 7 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2010-01-13 | goldsimon | Status | Need Info | Fixed | |
Assigned to | None | goldsimon | |||
Open/Closed | Open | Closed | |||
2010-01-10 | goldsimon | Status | None | Need Info | |
2009-10-29 | goldsimon | Summary | Processor specific porting needs flexibility in terms of placement of various memory pools. | Processor specific porting needs flexibility in terms of placement of various memory pools and heap | |
2009-05-01 | kieranm | Planned Release | 1.4.0 | ||
2009-04-09 | davidcl | Attached File | - | Added temp.diff, #17897 |
Powered by Savane 3.13-758e.
Corresponding source code
Done:
- the heap can be relocated by defining LWIP_RAM_HEAP_POINTER as a pointer to the memory's address;
- both the heap and the memp pools can be relocated by including an 'extern' definition (including the corresponding relocation attributes or pragmas) in cc.h