[PATCH rtems-libbsd] CONTRIBUTING: Sharpen priority development goals

Karel Gardas karel at functional.vision
Mon Feb 6 10:33:36 UTC 2023


On 2/6/23 05:16, Chris Johns wrote:
>> +   * A lot of different hardware uses LibBSD as network or USB stack or maybe in
>> +     the future even only for other subsystems.  Some of the targets have
>> +     hundreds of megabytes memory.  Others can only have a few megabytes (like
>> +     the ATSAMV71).  Make sure that changes don't increase the RAM / Flash size
>> +     of the default build so that it can't be used on the small targets.
> 
> This is not realistic or achievable and I find confusing the reasons it is being
> pushed over and over. I would have not have agreed to this being added before
> now and nothing has changed. The central reason for rejecting this statement is
> a change in FreeBSD may add a few meg of memory to the footprint and this type
> of statement would conflict with that addition and that in turn would conflict
> with the need for transparency of source. And as stated before transparency must
> be preferred.
> 
> System requirements are for the developers of those systems and not RTEMS.
> Derating designs is an important part of system design and not the domain of
> this project. Memory constrained systems can consider another networking stack
> option or bespoke changes internally maintained. That is a cost trade off no one
> here can help make.

 From the discussion it looks like guys from embedded brains push that 
policy forward I mean policy that memory consumption is somehow 
important metric for patch acceptance. Seeing their commit track log I 
would not oppose that rule that much as at the end of the day somebody 
needs to do the job and from the log it looks like embedded brains stay 
behind their word.

As an RTEMS user here, I'm curious if this discussion about few 
paragraphs in CONTRIBUTING file is not too much over-thinking of the 
issue. So far majority of patches were done by just three subjects: 
embedded brains, aorcorp and you. So I would assume that engineering 
discussion with respect for each other contribution and energy spent 
should result in a policy which may be vague and compromise but working 
well for what you all guys do for us RTEMS users here...

Thanks!
Karel

rtems at silence:~/git/rtems/ssh-rtems-libbsd$ git shortlog -s -n --all 
--no-merges
   1554  Sebastian Huber
    242  Christian Mauderer
    242  Joel Sherrill
    175  Chris Johns
    163  Jennifer Averett
     31  Kevin Kirspel
     31  Kinsey Moore
     25  Vijay Kumar Banerjee
     21  Jan Sommer
     12  Moyano, Gabriel
     12  Sichen Zhao



More information about the devel mailing list