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

[Christian MAUDERER]

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?

-- 
--------------------------------------------
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/