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

[Sebastian Huber]

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.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 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/