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

Thu Jan 26 09:31:27 UTC 2023

On 2023-01-26 10:26, Christian MAUDERER wrote:
> 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
> 
> 

Sorry, clicked on send to early:

... With the points above, we could analyze that problem, find out 
whether it increases the maintainence effort. If it does and we do _not_ 
all agree that it's worth the effort, that would be a functionality that 
shouldn't be included. In that case it maybe would be simpler to 
maintain the drivers in a separate repository with it's own upgrade 
mechanism or find another solution.

Best regards

Christian

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