Using linker-generated _end instead of KERNEL_MAX_SIZE

[mjrgh]

I'm building a fairly large program with Circle, and it took me a while to figure out that the reason it was crashing shortly after startup was that I needed to increase KERNEL_MAX_SIZE to accommodate the large image size. I realize that this doesn't affect many embedded programs, so it's not surprising that it's not documented as a basic configuration step, but it's really a bit of a pain to track down when you do need to change it.

I wonder if this could be made less fragile by getting rid of KERNEL_MAX_SIZE entirely, and basing the memory map on the "_end" symbol that the linker automatically generates to mark the end of the BSS area (and of the overall image). It looks like Circle's own usage of the various macros derived from KERNEL_MAX_SIZE are mostly isolated to the memory manager code and startup.S , so this might be doable without too much impact on Circle itself. However, the macros are exposed in the public headers, so if those are meant to be part of the public API, it might be too compatibility-breaking to consider.

If it's not feasible to make the memory sizing more dynamic, perhaps CMemorySystem could do a sanity check at startup, to make sure MEM_KERNEL_END >= reinterpret_cast<unsigned long>(&_end). An assert() probably wouldn't be ideal, since there typically isn't a logger available yet when CMemorySystem's ctor runs, but at least you'd get a hard crash immediately at startup rather than at some indeterminate time later. It's usually easier to track down the former than the latter.

[rsta2]

I understand the problem, but unfortunately I cannot see a perfect solution for it. I can only inform about system options, and actually I have done this here in the main README and here in the docs. KERNEL_MAX_SIZE is the first option in the file sysconfig.h, so it is at a prominent place.

[mjrgh]

Thanks for the reply. I figured that changing that low-level code would be too destabilizing, but I wanted to raise it in case you thought it was feasible. Some kind of fast-fail sanity check during initialization (like an assert) might still be worthwhile, though - resource limits like these can sneak up on you as a program evolves.

[rsta2]

I've added a check on the develop branch. We cannot inform the user that early, but better to halt the system, instead of risking to let the user search for spurious errors. Thanks for pointing on this!

[mjrgh]

Thanks!