On 2023-01-25 19:10, Peter Dufault wrote:
On Jan 25, 2023, at 10:55 , Gedare Bloom <ged...@rtems.org> wrote:
On Wed, Jan 25, 2023 at 2:25 AM Christian MAUDERER
<christian.maude...@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.maude...@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/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
