[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