@rdmark In case @akuker agrees to proceed as I suggested it may be useful if the web UI supports creating drive images of real devices by calling the rasdump tool. As rasdump cannot use the bus at the same time rascsi does, rascsi would have to be told to relinquish bus control (remote interface).
In the ideal case rasdump would offer a protobuf remote interface, and would support scanning for connected devices. The UI could then display a list of available devices to dump. This means major changes to rasdump, though.
What's your opinion on that? A problem with that approach might be that a protobuf interface requires a running rasdump process which is listening on a socket. But the UI could just start rasdump when needed, and terminate it again after all work is done. A running process would also be able to receive commands from the UI while the dump process is running, so that the UI could display a progress bar, for instance. Doing this is probably mandatory, because otherwise it's impossible to know how long the dump will still take.

Even better: rasdump should be integrated into rascsi. If rascsi receives a command that requires to switch from target to initiator mode, it can just do that, and later switch back. All in all that is a major effort, but definitely less than adding a protobuf interface to rasdump and figuring out how to avoid conflicts between rascsi and rasdump, and starting/stopping either the one or the other. rascsi also knows the image folder, i.e. it knows where dumped images should be stored.
Integrating rasdump into rascsi without adding any remote functionality would be the first step towards this goal.

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
4 Security Hotspots
19 Code Smells

0.2% Coverage
0.0% Duplication

@uweseimet When you say rascsi would have to relinquish bus control, would that mean that the process has to be terminated and then started up again after rasdump is finished? Or do you have some other mechanism in mind, in case we don't go down the road of integrating rasdump into rascsi?

The one argument I could think of not to integrate rasdump into rascsi would be the Unix philosophy or small, modular programs that work in unison. Rascsi already has a huge amount of functionality built into it and is quite a memory intensive program. This is just my 2 cents however.

Regardless, having a user friendly front end for dumping physical hard disk images and immediately making them available to the user as image files sounds like a very powerful and handy feature, indeed. I would be up for trying to make that work in the Web Interface.

@rdmark Regarding relinquishing bus control: If there are two different processes only one can use the bus, the other has to relinquish it.
I agree with what you say about the Unix philosophy, but a process that listens on sockets is not a regular Unix tool that does something when being started and then pipes the output to the next tool and so on. We are dealing with server processes here. Having two separate processes is a much bigger effort and requires more hardware resources than having just one, and you would have to duplicate a lot of functionality, like dealing with the network and with protobuf messages. This is comparable to what you have with web servers: There are not several of them on the same machine just because you have several websites/domains. There is a single server instead with multiple virtual hosts.

But instead of adding new tickets with features like that it might be better to first clean up/resolve the existing ones. Or to reject them, because they are not realistic. There are roughly these categories of existing backend tickets:

• Adding additional SCSI commands: This is the minority because at least for the existing device types there is not that much that can be added. As big as it is, the SCSI standard has a limited scope.
• Completely new features: Tickets like tape drive support, SCSI/USB bridge, BIN/CUE support, action hooks etc. require man weeks or even man months. Tickets of that kind should not be accepted unless the author is also going to implement them. Who else than the author is going to work on those, considering that a lot of expert knowledge (SCSI, Samplers, other protocols, Linux kernel potentially) is required? As far as I can tell since this project started regarding C++ it has essentially been a one-man-show, and for some of these tickets you even need SCSI hardware you can verify against, e.g. a streamer.
• Features just one or two users are interested in or plan to maybe be interested in. The X68000 stuff in particular, which is broken beyond repair. https://sonarcloud.io/component_measures?id=akuker_RASCSI&branch=develop says more than 1000 words. Who is going to maintain this code nightmare, which has more SonarCloud issues than it has lines of code? Who is going to add unit tests? This code should be discarded, because just like the SASI controller it binds resources and potentially blocks further development of other features from which more than just two users might profit from.
• Tickets dealing with low-level protocol issues like Mac Plus write error: Not able to receive 512 bytes of data #656. These are tricky and might require signal analyzer hardware. Also see Mac Plus write error: Not able to receive 512 bytes of data #656 (comment). Fix/verify sleep during DATA IN/DATA OUT/STATUS phase #949 may also be relevant in this context.
• Code improvements: Not that much left to do IMO when you do not take the X68000 stuff and scsimon into account. About 70-80% of the non-X68000 code are essentially new by now, and this new code is covered with unit tests very well. The code not covered often deals with files/sockets or not mockable (static) methods, where unit testing is hardly possible.

Just my two cents.

@rdmark In case @akuker agrees to proceed as I suggested it may be useful if the web UI supports creating drive images of real devices by calling the rasdump tool.

@uweseimet - in my opinion, I don't think we need to easily switch back and forth between rascsi mode and rasdump mode. IMHO, these are completely different use cases and most likely involve switching cables around (and we ALWAYS shut down our hardware before switching SCSI cables, right? ;-) )

Even better: rasdump should be integrated into rascsi. If rascsi receives a command that requires to switch from target to initiator mode, it can just do that, and later switch back. All in all that is a major effort, but definitely less than adding a protobuf interface to rasdump and figuring out how to avoid conflicts between rascsi and rasdump, and starting/stopping either the one or the other. rascsi also knows the image folder, i.e. it knows where dumped images should be stored. Integrating rasdump into rascsi without adding any remote functionality would be the first step towards this goal.

This scares me. I would have no objection to updating the web interface to be able to control rasdump. But IMHO, it should stop RASCSI, then run rasdump. Maybe a completely different tab or some way to differentiate that this is completely different functionality from normal rascsi operation.

Creating a wiki page with detailed instructions, screenshots and troubleshooting tips would accomplish about the same goal (IMHO).

@akuker The problem with the cables is a very good point, which I did not think of yet ;-). Let's just forget the whole thing. From a software perspective this would have been interesting, but it causes too many practical issues.