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

Thu Jan 26 09:26:42 UTC 2023

On 2023-01-25 19:10, Peter Dufault wrote:
> 
>> On Jan 25, 2023, at 10:55 , Gedare Bloom <gedare at rtems.org> wrote:
>>
>> 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
>>
> 
> I'm presenting my concerns without doing appropriate research.
> 
> This ties in to other needed RTEMS specifications, in particular, the specification of whsy light-weight IP can support, and if it is possible to have a project to tie "libbsd" drivers into the LWIP infrastructure (*I* don't know if that's possible).  Yes, I want my cake, and eat it too.
> 
> "It would be great" if it is clear what small memory platforms lose when going with "LWIP" vs "libbsd", and how easy to switch between the stacks given a supported driver.
> 
> Peter

Hello Peter,

thanks for the input. From my point of view, lwIP and libbsd have 
different use cases. lwIP is a great stack if only basic functionallity 
is necessary. From a first guess, I would expect that lwIP doesn't have 
network functionallity like VLAN, packet filter and similar advanced 
functions. But please don't forget: libbsd is more than a network stack. 
It started as a USB stack and can still offer that functionallity (there 
is a buildset that only builds that part). It can be used as a SDMMC 
stack (haven't seen an application yet that only uses that part). A GSoC 
project added HDMI support for the beagle. So libbsd is now more a 
driver framework and not only a network stack.

It could be really interesting to make libbsd modular enough that we can 
use the libbsd network drivers - without the whole stack - together with 
lwIP. That would be a great use case for the maximum necessary 
modularity: Compiling only network drivers without the rest. With the 
points above, we could analyze that problem, find out whether it 
increases maintainence

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