Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
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 wrote: On Wed, Jan 25, 2023 at 2:25 AM Christian MAUDERER 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
Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
On 2023-01-25 19:10, Peter Dufault wrote: On Jan 25, 2023, at 10:55 , Gedare Bloom wrote: On Wed, Jan 25, 2023 at 2:25 AM Christian MAUDERER 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
Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
> On Jan 25, 2023, at 10:55 , Gedare Bloom wrote: > > On Wed, Jan 25, 2023 at 2:25 AM Christian MAUDERER > 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
Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
On Wed, Jan 25, 2023 at 2:25 AM Christian MAUDERER 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 > > embedded brains GmbH > Herr Christian MAUDERER > Dornierstr. 4 > 82178 Puchheim > Germany > email: christian.maude...@embedded-brains.de > phone: +49-89-18 94 741 - 18 >
Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
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
Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
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. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 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
Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
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? -- 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
Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
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. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 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
Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
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.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
Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
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 Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 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
Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
Hello, 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. wkr, Thomas. Am 23.01.23 um 14:33 schrieb Christian MAUDERER: Hello, like suggested earlier in the original discussion I would suggest to prioritize our development goals for libbsd and later evaluate the two problems discussed in the thread based on this. Let's first agree on development goals (that also can be added to the libbsd documentation). From the thread and responses, I currently have collected the following goals / priorities. I replaced my original extensibility and debuggability with Joels transparency because it's a good summary term for these two points. From highest to lowest priority: - 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. - Real time capabilities: No hard real time requirements for libbsd core but we have to make sure that it doesn't have a negative impact on other subsystems. - Performance: Whether libbsd performes well enough in the typical use cases. That means (for example): If it makes the system more maintainable, the performance isn't that important. If it reduces the size, we can trade off some performance or real time capabilities. Would you prioritize different? Did I miss some additional points from the discussion? Best regards Christian On 2023-01-20 08:32, Christian MAUDERER wrote: Hello, recently an internal discussion about updates in the libbsd started. All who participated in the discussion agreed that we should move the discussion to a public one. Below you can find the mail thread. It's oldest mail first. Mails are split with lines of = signs. I removed some duplicated mail text in case there were no inline comments. The date/time of the mails are in my current locale which is UTC+1. Best regards Christian = On 2023-01-03 16:52, Thomas DOERFLER wrote: Hello, first of all I wish you all a healthy, happy and successful new year. Unfortunately I already have to re-raise an issue: One of our customers has asked us about the RTEMS libbsd update policy. Since we still use a rather old libbsd version, it contains "OpenSSL 1.1.1d-freebsd 10 Sep 2019", there are many openSSL fixes missing when using RTEMS, and this most likely is true for other parts of libbsd. IMHO we should find a way to overcome the current libbsd update blocking points and try to stay close to the FreeBSD code (maybe in a 1-3 month interval). AFAIK the big blocking point are the different views around changes of the file descriptor handling between RTEMS and BSD (this may be a bit off the real topic, I am not yet into the details). In the next week I would like to get things rolling to see the pros and cons of both possible implementations and I would be happy if those closely involved would support this. Apart from the current blocking point, can we agree that staying close the the FreeBSD code (with a 1-3 month update/sync interval) would be desirable? Kind regards to you all, Thomas. = On 2023-01-12 01:24, Gedare Bloom wrote: Hi Thomas, I think the goal you have stated is laudable and fits with the initial design goals of libbsd. I will take a closer look at this topic and report back soon, I hope. I have remained (purposefully) ignorant about libbsd evolution over time, but I guess it is time for me to learn a bit more and catch up. From what I have understood about the current blocking issue, it has to do with the changes that were made to use FreeBSD File Descriptors and the VFS. However, one of the main problems that was noted actually appears to be just related to the size increase caused by the syscall glue implemented in a single .c file. So, I will plan to start my libbsd learning adventure by trying to split that .c file apart into separate build components to see how/if that alleviates the linked image size. If successful, that should get us closer. I think we can then revisit whether or not the FreeBSD File Descriptors themselves are in fact problematic. It would also be helpful to decide if we want to clarify any requirements for libbsd maintenance. So, for example, the ability to keep it updated on a rolling basis would require good automation and validation that changes/updates remain usable. It would appear that there are some
Prioritizing and documenting libbsd development goals (was: libbsd updates)
Hello, like suggested earlier in the original discussion I would suggest to prioritize our development goals for libbsd and later evaluate the two problems discussed in the thread based on this. Let's first agree on development goals (that also can be added to the libbsd documentation). From the thread and responses, I currently have collected the following goals / priorities. I replaced my original extensibility and debuggability with Joels transparency because it's a good summary term for these two points. From highest to lowest priority: - 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. - Real time capabilities: No hard real time requirements for libbsd core but we have to make sure that it doesn't have a negative impact on other subsystems. - Performance: Whether libbsd performes well enough in the typical use cases. That means (for example): If it makes the system more maintainable, the performance isn't that important. If it reduces the size, we can trade off some performance or real time capabilities. Would you prioritize different? Did I miss some additional points from the discussion? Best regards Christian On 2023-01-20 08:32, Christian MAUDERER wrote: Hello, recently an internal discussion about updates in the libbsd started. All who participated in the discussion agreed that we should move the discussion to a public one. Below you can find the mail thread. It's oldest mail first. Mails are split with lines of = signs. I removed some duplicated mail text in case there were no inline comments. The date/time of the mails are in my current locale which is UTC+1. Best regards Christian = On 2023-01-03 16:52, Thomas DOERFLER wrote: Hello, first of all I wish you all a healthy, happy and successful new year. Unfortunately I already have to re-raise an issue: One of our customers has asked us about the RTEMS libbsd update policy. Since we still use a rather old libbsd version, it contains "OpenSSL 1.1.1d-freebsd 10 Sep 2019", there are many openSSL fixes missing when using RTEMS, and this most likely is true for other parts of libbsd. IMHO we should find a way to overcome the current libbsd update blocking points and try to stay close to the FreeBSD code (maybe in a 1-3 month interval). AFAIK the big blocking point are the different views around changes of the file descriptor handling between RTEMS and BSD (this may be a bit off the real topic, I am not yet into the details). In the next week I would like to get things rolling to see the pros and cons of both possible implementations and I would be happy if those closely involved would support this. Apart from the current blocking point, can we agree that staying close the the FreeBSD code (with a 1-3 month update/sync interval) would be desirable? Kind regards to you all, Thomas. = On 2023-01-12 01:24, Gedare Bloom wrote: Hi Thomas, I think the goal you have stated is laudable and fits with the initial design goals of libbsd. I will take a closer look at this topic and report back soon, I hope. I have remained (purposefully) ignorant about libbsd evolution over time, but I guess it is time for me to learn a bit more and catch up. From what I have understood about the current blocking issue, it has to do with the changes that were made to use FreeBSD File Descriptors and the VFS. However, one of the main problems that was noted actually appears to be just related to the size increase caused by the syscall glue implemented in a single .c file. So, I will plan to start my libbsd learning adventure by trying to split that .c file apart into separate build components to see how/if that alleviates the linked image size. If successful, that should get us closer. I think we can then revisit whether or not the FreeBSD File Descriptors themselves are in fact problematic. It would also be helpful to decide if we want to clarify any requirements for libbsd maintenance. So, for example, the ability to keep it updated on a rolling basis would require good automation and validation that changes/updates remain usable. It would appear that there are some minimum resource requirements that some users of libbsd would like to remain under if possible. To ensure that would require establishing what platform(s) have resource requirements for using libbsd, and adding configurations/testing to check for when those resources are exceeded by an update. Because it is entirely
