This is the mail archive of the ecos-patches@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug 1001116] Instruct lwIP to use special section for buffers and heap.


Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001116

--- Comment #12 from Ilija Kocho <ilijak@siva.com.mk> 2011-01-29 12:51:18 GMT ---
(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > "Make it as simple as you can, and no simpler" :-) But,
> > > 
> > > I would not use calculated command as you proposed
> > 
> > Why not use calculated?
> 
> To be clear. I have only wanted an empty MEM_SECTION definition by default.

Don't we have it since the beginning? I have done backward compatibility checks
after every substantial change.

> 
> > By using calculated value we have a single entry point for section name.
> > It can be further enhanced by following:
> > 
> >     cdl_component CYGDAT_LWIP_MEM_SECTION_NAME {
> >           ...
> >           legal_values { "ahb_bss" "ahb_0" }
> >           ...
> >     }
> 
> Ah, I missed that you need a choice from the list.

It's an outcome from our discussion. Frankly, I'm not yet sure what's more
appropriate: to restrict user choice to available sections (safe), or give more
freedom?

[SNIP]

> ...so, I enterred a mess when I have been pointed on the 'booldata' above.

IMO booldata flavor is OK for CYGDAT_LWIP_MEM_SECTION_NAME, since it provides
for user override. Someone may want to place lwIP buffers back in main memory
(if restricted resources for lwIP and application are acceptable) and use
additional memory sections for something else.

On the other hand CYGDAT_LWIP_MEM_SECTION needn't/shouldn't be booldata since
it's (non)definition depends on CYGDAT_LWIP_MEM_SECTION_NAME. I have changed to
it to data (pse see revised snippets below).

> 
> > > Comments?
> > 
> > The combination that you are proposing inherently raises a conflict which I
> > prefer to avoid.
> > However I tried it and the conflict resolution offered by configtool is not
> > what we want - it offers CYGDAT_LWIP_MEM_SECTION_NAME = 0 ??
> 
> Yes, I'm sorry, then that can be
> 
> cdl_package CYGPKG_NET_LWIP {
>     ...
>     cdl_option CYGSEM_LWIP_MEM_SECTION {
>         display     "Relocate memory pools"
>         flavor      bool
>         calculated  is_active(CYGDAT_LWIP_MEM_SECTION_NAME)
>         ...
>     }
> }
> 

Wouldn't it be clearer in configtool if CYGSEM_LWIP_MEM_SECTION is "grayed"
when we have no memory section provided?
Hence active_if CYGDAT_LWIP_MEM_SECTION_NAME


> cdl_package CYGPKG_HAL_... {
>     ...
>     cdl_option CYGDAT_LWIP_MEM_SECTION_NAME {
>         display       "Name of section"
>         flavor        data
>         default_value { "\".foo\"" }
>         legal_values  { "\".foo\"" "\".bar\"" "\".baz\"" }
>         ...
>     }
> }
> 

Ref. discussion on booldata flavoring of CYGDAT_LWIP_MEM_SECTION_NAME above.


> and the check will be simple
> 
> #if CYGSEM_LWIP_MEM_SECTION
> #include <cyg/infra/cyg_type.h>
> #define MEM_SECTION CYGBLD_ATTRIB_SECTION(CYGDAT_LWIP_MEM_SECTION_NAME)
> #else
> #define MEM_SECTION
> #endif
> 
> Well, if HAL does not provide CYGDAT_LWIP_MEM_SECTION_NAME, that lwIP's
> CYGSEM_LWIP_MEM_SECTION will be not defined and other targets (the most)
> will be happy with
> 
> #define MEM_SECTION
> 
> Your target's CDL will turn on CDL option CYGSEM_LWIP_MEM_SECTION and
> memory section name will be specified.
> 
> I hope I get it what you looking for.

Doesn't the same also apply to code proposed in comment #8?
However there are 2 things I would change in comment #8 code:
  - CYGSEM_LWIP_MEM_SECTION to be of flavor data
  - CYGSEM_LWIP_MEM_SECTION_NAME to be no_define (only CYGSEM_LWIP_MEM_SECTION
is needed by C code)

Also there is one point for further discussion: 
  - Concatenation or plain strings?

IMO it would depend on resolution for section related macros proposed in
http://bugs.ecos.sourceware.org/attachment.cgi?id=1088 to Bug 1001114 . 

For reference, here is a digest of all code snippets as are in my current
build:

-----------------
cdl_package CYGPKG_NET_LWIP {
      ...
        cdl_option CYGDAT_LWIP_MEM_SECTION {
            display "Special memory section for lwIP buffers."
            active_if CYGDAT_LWIP_MEM_SECTION_NAME
            requires CYGDAT_LWIP_MEM_SECTION_NAME
            flavor data
            calculated { "\"." . CYGDAT_LWIP_MEM_SECTION_NAME . "\"" }
            description "..."
        }
      ...
}
---------------
cdl_package CYGPKG_HAL_FOO_BAR {
     ...
    cdl_component CYGDAT_LWIP_MEM_SECTION_NAME {
        flavor booldata
        active_if CYGPKG_NET_LWIP
        parent CYGOPT_LWIP_MEM_PLF_SPEC
        default_value { "foo" }
        legal_values { "foo" "bar" }
        no_define
        display "..." 
    }
     ...
}
----------------
// lwipopts.h

#ifdef CYGDAT_LWIP_MEM_SECTION
#include <cyg/infra/cyg_type.h>
#define MEM_SECTION CYGBLD_ATTRIB_SECTION(CYGDAT_LWIP_MEM_SECTION)
#else
#define MEM_SECTION
#endif

--------------

Note: Following section related macros in are stored in lpc17xx_misc.c
temporarily until the issue is resolved. If accepted, they should be stored in
some(probably architecture) HAL header.

// lpc17xx_misc.c

//===================================
// Special memory section macros
//===================================

#define SECTION_START(_name_) (__ ## _name_ ## _start)
#define SECTION_END(_name_) (__ ## _name_ ## _end)

#define SECTION_USR(_name_) \
__externC cyg_uint32 SECTION_START(_name_); \
__externC cyg_uint32 SECTION_END(_name_)

#define SECTION_CLEAR(_name_) hal_section_clear(&SECTION_START(_name_),
&SECTION_END(_name_))

#if defined(CYGDAT_LWIP_SECTION_NAME)
SECTION_USR(CYGDAT_LWIP_SECTION_NAME);
#endif

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]