Refactor zebra.c

Issue #1545 new
ppluciennik created an issue

My idea is to split zebra.c. I see that there are several features in this file (like spotmeter, focus peaking, waveform) which could be moved to separate files.

I'm eager to do the split and possibly add some benchmarks (if it will be possible).

What do you think about it?

Comments (24)

  1. Alex

    Yes. In the near future, we hope to move most stuff to modules, so they can be loaded on the fly (only when needed).

    CHDK module system is pretty good IMO:

    They only have fully portable code in modules, and I think it's good for us to do the same. Right now, our first non-trivial modules (lv_rec and raw_rec) are also portable (same object file for all cameras).

  2. ppluciennik reporter

    Sounds good. I could start to work on this, if you don't mind. Maybe I could start by moving for example focus peaking to module or something else.

  3. Alex

    Yep. I'd move waveform and vectorscope to modules first. Zebra and histograms are quite tightly integrated with other stuff, so it will be harder.

    The module engine is also very young, so it's likely to run into limitations.

  4. ppluciennik reporter

    I've tried to enable CONFIG_MODULES =y and CONFIG_TCC=y. The problem I'm facing is that ML doesn't start. Problem is caused by enabling CONFIG_TCC. Have you encountered such problem?

  5. Giovanni Nanomad Condello

    My only concern is that cameras like the 1100D and the upcoming 100D won't be able to load modules due to dynamic memory constraints...A way to bake some modules into the autoexec.bin would be nice (if possible)

  6. ppluciennik reporter

    I thought about some fallback mechanism either compile code as a module or as normal object. Actually my idea is to move code to "module" and compile it (which actually is fallback solution) and then move forward. Having fallback solution shouldn't be hard.

  7. Alex

    From TCC we only need to keep the ELF loading code (which I guess it's small). The compiler part will be loaded as a module too, for running scripts.

    gcc removes unused functions as long as they are declared static. Or, with whole program optimizations, which didn't quite work for me.

  8. ppluciennik reporter

    Patching TCC is required to reduce dependencies, because tcc_add_file_internal uses tcc_compile. Even with removing tcc_compile dependency binary size is still bigger than i expect.

    I played a bit with -ffunction-sections -fdata-sections and --gc-sections, but results weren't satisfactory.

  9. Alex

    Yes, that's what I want to do: patch TCC and keep only the elf loading part. tcc_compile is only called if you want to add a .c file via tcc_add_file_internal, and we don't need that.

    The full-blown TCC can stay as a module, and only loaded when we run scripts.

  10. Alex

    If you can take a look at it, would be great. I can do it, but it will take a while with all this raw madness :P

  11. Alex

    Plugins are deprecated and can be removed. Modules use standard file formats (object files) and don't require source code hacks.

    We can also cleanup the OS_FUNCTION stuff from dryos.h and other headers, since they belong to plugins.

  12. Giovanni Nanomad Condello

    I bet he's talking about refactoring :)

    I'd split this issue into 3 so we can keep track of them easily:

    • Deprecate PLUGINS code (clean-up macros, remove unusued sources and stuff inside Makefiles)

    • Re-package vectorscope as a module

    • Split TCC ELF loader from the actual compiler

  13. ppluciennik reporter

    Of course refactoring task :) First I'll handle TCC since enabling modules on 60D hits binary limit and ML doesn't start ;) Then I'll move vectorscope (maybe something more) to module and then obsolete plugins (or move it to modules).

  14. Alex

    Tip: to preserve menu order when moving stuff to modules, replace the menu entry definition with MENU_PLACEHOLDER("Vectorscope"). See mem_prot and mrc_dump - these two appear in the Debug menu, exactly where I want them to be.

  15. ppluciennik reporter

    May I freely modify files in tcc directory, or should I make as less changes as possible? I'm thinking about putting all needed functions into one file to eliminate chances of having not used functions in binary.

  16. Log in to comment