SASI code removal, error handling update, bug fixes, code cleanup

[uweseimet]

After approving, I would like to merge into develop myself, because I may want to add some comments to the commit message.

The most important changes:

• Removed the SASI controller code
• New controller management. There is a new controller base class AbstractController and a class ControllerManager managing the controller lifecycle. The lifecycle management was removed from rasci.cpp and is covered by unit tests.
• New device management. The DeviceFactory manages the device lifecycle instead of rascsi.cpp. The new code is covered by unit tests.
• The lifecycle managment uses C++ collections with variable size instead of arrays with hard-coded sizes.
• The ScsiController method contains most of what was previously contained in scsidev_ctrl.cpp plus the code from sasidev_ctrl.cpp that was relevant for SCSI.
• scsi_command_util contains helper methods used for identical SCSI command implementations of more than one device
• Devices know their controllers, so that the controller instance does not need to be passed to each SCSI command. This change helps to decouple the devices from the controller. The phase_handler interface is also part of this decoupling.
• Use scsi_command_exception for propagating SCSI command execution errors, This resolves issues with the previous error handling, which was based on return values and often on magic numbers.
• Removed legacy SCSI error codes, all errors are now encoded by sense_key::, asc:: and status::.
• Fixed various warnings reported with -Wextra, -Weffc++ and -Wpedantic.
• Use constructor member initialization lists (recommended for ISO C++)
• Consistently use new/delete instead of malloc/free (recommended for ISO C++), resulting in better type safety and error handling
• Replaced variable sized arrays on the stack (violates ISO C++ and can cause a stack overflow)
• Replaced NULL by nullptr (recommended for C++), resulting in better type safety
• Use more const member functions in order to avoid side effects
• The format device page can now also be changed for hard disk drives (Fujitsu M2624S supports this, for instance), not just for MOs.
• Better encapsulation, updated access specifiers in many places
• Removed unused methods and method arguments
• Fixed a number of TODOs
• Added/updated unit tests for a lot of non-legacy classes
• Makefile support for creating HTML coverage reports with lcov/genhtml

gcov usage example (make flags must include --coverage):

>make test
>gcov --relative-only obj/fullspec/abstract_controller.cpp
File 'controllers/abstract_controller.cpp'
Lines executed:92.59% of 27
Creating 'abstract_controller.cpp.gcov'

File 'devices/device.h'
Lines executed:0.00% of 1
Creating 'device.h.gcov'

Lines executed:89.29% of 28

Or nicer with lcov instead of gcov:

>lcov -q -c -d . --include '*/RASCSI/*' --exclude '*/test*' -o rascsi.dat
>genhtml -q -o coverage --legend rascsi.dat

There is a new Makefile 'coverage' target combining all these steps. The folder with the generated HTML is 'coverage'.

At least temporarily up to date code coverage results for a selected branch are published regularly.

@akuker Hope you are done with automation soon!

[uweseimet]

@akuker I just updated my first comment in order to provide more details on the changes. This will hopefully help with the review.

[uweseimet]

@akuker By accident I committed one change (adding -lpthread) to scsi_removal instead of scsi_removal_cleanup, I'm sorry for that ...

[akuker]

@akuker By accident I committed one change (adding -lpthread) to scsi_removal instead of scsi_removal_cleanup, I'm sorry for that ...

No problem. Thank you for letting me know!! FYI: I'm going to dedicate some time to this PR this weekend.

@uweseimet - side question - do you have a configuration/profile for code stye/formatting that you've been using? I'm wondering about committing a clang-format or uncrustify configuration file for the C++ side of things. (Uncrustify would be a lot smaller impact to the pre-built image (488k) vs clang-format wanted to pull in 135MB of stuff.

[uweseimet]

@akuker Thank you for spending your time on the PR this weekd.

Regarding formatting, I dont'use a special formatting. I just tried to format the code manually in a way that I thought was used in most of the existing code. Regarding the usage of tabs vs. blanks and indentation Eclipse appears to look at the existing file and handles this automatically. Emacs also does it like this as far as I know.

I would be fine with reformatting the code in a consistent way, but it should be a format the usual IDEs (Eclipse in particular) support, so that once the code was reformatted the IDE preserves it. Otherwise things become very inconvenient, as I learned in a project where different IDE were used and it was not possible to configure these IDEs to use the same formatting rules.
There is an Eclipse plugin (CppStyle) that is supposed to integrate clang-format, but I don't know how well this works. Personally I would prefer to use one of the four styles integrated in Eclipse and not an external tool at all. On first sight the K&R style seems to be closed to the current code format.

I'm not sure what you mean with an impact on the pre-built image, though.

[akuker]

I'm not sure what you mean with an impact on the pre-built image, though.

With every release, we put out a Raspberry Pi OS image that can be directly flashed to an SD card. I'd like to keep that as small and light-weight as possible. Whatever tool we use, I'm assuming we'd want to include it in the release disk image.

The last image is at the bottom of this page: https://github.com/akuker/RASCSI/releases/tag/v22.08.01

[uweseimet]

@akuker I'm afraid I don't see the connection between code formatting and the image. My guess now is that the image contains the sources and you would like to consistently format the code that is added to the image. Not necessarily the code that is in git. Am I right? In this case I cannot provide any useful feedback because I have never used external formatting tools.

Eclipse (at least for Java sources, not sure about C++) optionally automatically formats the code according to the configured style when saving a source file. In order to consistently format a project's (Java) sources, you typcially format everything with Eclipse once iin the configured format. Then you ensure that you have enabled the format-on-save option. This way the formatting stays consistent without any additional actions.

[akuker]

@akuker I'm afraid I don't see the connection between code formatting and the image. My guess now is that now is that the image contains the sources and you would like to consistently format the code that is added to the image. Not necessarily the code that is in git. Am I right? In this case I cannot provide any useful feedback because I have never used external formatting tools.

Sorry... I'm not articulating my thoughts very well. I want to add the C++ code formatting as part of either the git commit hook or as part of the 'nightly' build process. It really has very little to do with the image. I just want to pick a tool that is reasonably small so we can include it in the default image.

After a little more research, astyle looks like a potentially good option. There is an ecplise plugin for it, and also a VS Code plugin.

I'm getting ahead of myself though - lets get this PR done first.

[uweseimet]

@akuker Using git commit hooks would likely cause issues because usually you have open editors in your IDE or editor. If code is reformatted during the commit, the code in the filesystem (modified during the commit) differs from the code in the editors. This would trigger IDE or editor warnings for any file that has changed externally, This can be very annoying. It's as if a third person takes away control of your files and modifies them while you are editing.

[akuker]

Looks good! Just a couple comments/questions. Thank you @uweseimet !!

[uweseimet]

@akuker Thank you for reviewing! Please note that there is a sasi_removal_cleanup branch with (only a few lines) related changes. In the ideal case these changes would be merged into sasi_removal before merging everything together. Would be great if you could have a look at these changes.
It paid off to also compile with clang. One of the warnings reported was actually a bug. With the sasi_removal_cleanup branch clang is happy now and all warnings are gone.

I just merged develop into sasi_removal.

[akuker]

@akuker Thank you for reviewing! Please note that there is a sasi_removal_cleanup branch with (only a few lines) related changes. In the ideal case these changes would be merged into sasi_removal before merging everything together. Would be great if you could have a look at these changes.

I took a look and have no comments. feel free to merge them into this PR, then I'll approve.

It paid off to also compile with clang. One of the warnings reported was actually a bug. With the sasi_removal_cleanup branch clang is happy now and all warnings are gone.

So, maybe I should get some static analysis set up? ;-)

[uweseimet]

@akuker I am goint to merge sasi_removal_cleanup and will report back when I am done.

Regarding code analysis I guess you already know that I would like this ;-). Relying on compier warnings (even with -pedantic or -Weffc++) only is not really helpful anymore, because there are hardly any warnings left. And I expect a static analysis to find more valuable (and trickier to address) issues. At least this is the case with tools like SonarQube, which I use for Java and Kotlin anaysis. It's just a matter of time until these warnings are also gone, because you learn where the issues are, why they are issues, and how to avoid them before checking in.
Esoecially for the legacy code (cfilesystem.cpp, etc.) I expect an analysis tool to have many complains. WRT to the new code the results will hopefuly be better.

[uweseimet]

@akuker Merge done.

[akuker]

Approved! Thanks!

[akuker]

@uweseimet - can we delete this branch? Or did you want to continue developing on it?

[uweseimet]

@akuker I would like to keep it for at least some days, in case an issue pops up where individual commits might be relevant.

[akuker]

Sounds good. Thanks!