On Mon, Apr 17, 2023 at 9:55 PM Chris Johns <chr...@rtems.org> wrote: > > On 18/4/2023 1:48 pm, Gedare Bloom wrote: > > On Sun, Apr 16, 2023 at 6:48 PM Aaron Nyholm > > <aaron.nyh...@unfoldedeffective.com> wrote: > >> As for the RTEMS_FLASHDEV_MAX_REGIONS being set at 32 I chose the value as > >> it seamed a good balance between memory usage and function. I wanted to > >> avoid using malloc as your previous feedback suggested. If configurable > >> size is necessary what’s the best way to approach it without using malloc? > >> > > A configure-time option may be viable, e.g., spec/build/cpukit/opt* > > You should probably elevate that question to its own email thread to > > get other opinions. > > Is there an option that shows how to control a defined in an API header? > This has mostly been done in the past at a BSP level, so there are plenty of examples within BSP drivers and frameworks. Whether it is suitable to a cpukit driver framework is something I don't really know.
A quick example could be: BSP_CONSOLE_BAUD used in bsps/powerpc/shared/console define in spec/build/bsps/optconsolebaud.yml I'm not saying this is for sure the right way to do this, but I think it is worth thinking through. I think you would have to avoid using the define in the header itself to make it portable. The way it's defined in this code can be done with a RTEMS_ZERO_LENGTH_ARRAY. Then the driver that instantiates the structure can determine for itself the size of how many regions to support. Even that would be an improvement to the current hard-coded method. The size itself could be made a field of the rtems_flashdev that the driver would setup at init time. Whether it is made configurable in the spec/build approach, or determined by the driver itself, is less concerning to me than the fact it is currently not configurable at all and is assumed to be sufficient for all flash drivers to be 32. > I have a quick look and could not see anything. > > Thanks > Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel