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