[lwip-members] Re: [lwip-users] RFC: PBUF_FLAG_* must be orthogonal

[David Haas]

Hi Leon,

So what does PBUF_FLAG_ROM actually mean to the pbuf code? I think the 
PBUF_FLAG_REF case covers it.

I actually don't think we need a bitmapped flag here. I think an 
enumeration makes more sense.

As I said before, I also think we can gain a lot of speed by getting rid 
of PBUF_RAM entirely.

regards,
David.

Leon Woestenberg wrote:

> Hello,
>
> The PBUF_FLAG_* constants are only used within pbuf.c.
>
> However, the defines are not really orthogonal bit flags at this time, but
> actually are used as "pbuf types", each value a different type.
>
> In order to optimize the code base for all different cases, I propose the
> change of the PBUF_FLAG_* meaning as follows:
>
> PBUF_FLAG_ROM: payload is in ROM (otherwise, pbuf is in RAM)
> PBUF_FLAG_REF: payload is referenced externally (if not set, payload is
> internal to pbuf)
> PBUF_FLAG_POOL: pbuf is from pool (otherwise, dynamically allocated)
>
> Now, depending on the argument given to pbuf_alloc():
>
> PBUF_RAM type pbuf has flag 0.
> PBUF_ROM type pbuf has flags PBUF_FLAG_ROM | PBUF_FLAG_REF
> PBUF_REF type pbuf has flags
> PBUF_FLAG_REF
> PBUF_POOL type pbuf has flags PBUF_FLAG_POOL.
>
> but more combinations are possible:
>
> PBUF_FLAG_POOL | PBUF_FLAG_REF
> PBUF_FLAG_POOL | PBUF_FLAG_REF | PBUF_FLAG_ROM
>
> which allows for an improved pbuf pool system.
>
> As said, changing the flag implementation will not affect other modules, as
> they
> are pbuf internal.
>
> Regards,
>
> Leon.
>
>
>
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/lwip-users
>
>
>