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

[Christian MAUDERER]

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?

Best regards

Christian

On 2023-01-23 16:43, Sebastian Huber wrote:
> On 23.01.23 16:39, Thomas DOERFLER wrote:
>>
>> since we are maintaining an RTOS: IMHO Real time capabilities would 
>> need a higher level, even above code/RAM sizes.
>>
>> Meaining that the libbsd functionality should not have a (significant) 
>> negative impact on RTEMS tasks NOT using libbsd.
> 
> There is actually a good example for this area in libbsd, the Epoch 
> Based Reclamation.  It has an RTEMS-specific implementation which 
> required to add new features to the low level thread dispatching and 
> scheduling implementation. In particular, the support for thread pinning.
> 

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