Prioritizing and documenting libbsd development goals (was: libbsd updates)

Wed Jan 25 15:55:29 UTC 2023

On Wed, Jan 25, 2023 at 2:25 AM Christian MAUDERER
<christian.mauderer at embedded-brains.de> wrote:
>
> On 2023-01-25 10:05, Sebastian Huber wrote:
> > On 25.01.23 10:01, Christian MAUDERER wrote:
> >> On 2023-01-25 09:59, Sebastian Huber wrote:
> >>> On 25.01.23 09:52, Christian MAUDERER wrote:
> >>>> OK. Updated list based on Thomas and Sebastians feedback:
> >>>>
> >>>>  From highest to lowest priority:
> >>>>
> >>>> - Real time capabilities: No hard real time requirements for libbsd
> >>>> core, but we have to make sure that it doesn't have a (relevant)
> >>>> negative impact on other subsystems.
> >>>>
> >>>> - Maintainability: How easy is it for the people doing the main
> >>>> maintenance tasks to do that work.
> >>>>
> >>>> - Transparency: How easy it is to understand the code? Relevant for
> >>>> extending and debugging.
> >>>>
> >>>> - Code and RAM sizes (or other hardware requirements): Whether we
> >>>> meet the minimum hardware requirements.
> >>>>
> >>>> - Modularity: How well and easy the system can be adapted to target
> >>>> applications. Have only few official ways to enable / disable
> >>>> modules in the subsystem.
> >>>>
> >>>> - Performance: Whether libbsd performs well enough in the typical
> >>>> use cases.
> >>>>
> >>>> Any more suggestions for the order? Like I said, I would like to
> >>>> integrate that to the libbsd documentation as goals for that
> >>>> subsystem that can be used to evaluate different approaches for
> >>>> implementing something. Would be good to have some more feedback
> >>>> from others too.
> >>>>
> >>>> For example: I prioritized maintainability over transparency. That
> >>>> means that we might choose a solution that's simpler to maintain but
> >>>> makes it harder to integrate new modules. Is that OK?
> >>>>
> >>>> Similar the order of modularity and code / RAM size can be an issue:
> >>>> Most of the time these should go well together. But it's quite
> >>>> possible that some nice modular configuration options need extra
> >>>> code compared to less nice methods. From my point of view we target
> >>>> embedded systems where code and RAM size is more important. But I'm
> >>>> not sure that this is the focus for everyone else too?
> >>>
> >>> I would not give the minimum RAM size such a low priority. libbsd
> >>> used to work on systems with 16MiB. If you add new things which
> >>> require additional 4MiB even if you don't use the stuff, then you
> >>> simply kick out systems which used to work with libbsd.
> >>>
> >>
> >> So no lower than modularity. Should it be higher than transparency or
> >> maintainability? From the earlier comments I don't expect that it
> >> should be higher than (core) real time capability.
> >>
> >> What would be your preferred order?
> >
> > Lets say you are a user of libbsd version X. Then you want to update to
> > version X + 1. Version X + 1 no longer works on your system, because
> > libbsd needs more RAM than you have. Would you really give this user an
> > answer like this:
> >
> > Sorry, maintainability and transparency is more important for us, so
> > please stick to version X.
> >
>
> Regarding code / RAM size versus maintainability:
>
> Maintainability does also include the upgrade process to newer base
> versions of FreeBSD. So if it's more important that code size doesn't
> increase compared to how easy libbsd is to maintain, that can make
> upgrades to newer FreeBSD versions _very_ difficult. I don't think that
> would be a good trade.
>
> Code size versus transparency (how easy it is for someone new to start
> development and how easy it is to debug through the code) is a bit more
> opinion based. The current order is from what I have understood in the
> discussion. I don't have a problem to re-order these.
>
> Note: I'm OK with most orders as long as most of the maintainers can
> agree on one.
> --

Thanks for taking this on. Instead of a strict priority for the goals,
we might consider a limited set of different priorities that require
judgment to make good trade-offs. In this case, I would suggest the
following as somewhat equivalent goals, and the sets in priority
order:

1. Real-time Impacts + Maintainability Loss
2. Transparency Loss + Modularity Loss + Code/RAM Size Increase
3. Performance Loss

I wrote each goal now as a "minimize" objective. I think it is not
possible to establish strict priorities on these objectives.

Good engineering requires understanding and making good tradeoffs. I
believe that #1 addresses the highest requirements we place on RTEMS
and the libbsd philosophy.

#2 leaves us with the burden of discussing and debating when tradeoffs
are made. It may be better in some cases to increase code size by
increasing modularity, but in other cases it may be better to reduce
transparency to reduce code size.

Gedare

> --------------------------------------------
> embedded brains GmbH
> Herr Christian MAUDERER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email:  christian.mauderer at embedded-brains.de
> phone:  +49-89-18 94 741 - 18
> mobile: +49-176-152 206 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel