Tweet
I'll create a new thread at some point. This thread includes some good ideas, like misfire's suggestion for a VFS based on FUSE; I want to do this, but as an extension to the base SRDP commands.
Why am I thinking of this now? Because it's the only practical way to hook file I/O streams, like stdin/out/err. For example on GameCube, the OS_Report() function would be hooked to dump messages to the "stdout" stream (itself exposed to the file system through FUSE as /dev/stdout) and OS_Panic() would dump to the stderr stream (/dev/stderr). So, rather than an SRDP command to initialize these hooks and listen to separate streams, a completely separate "SRDP-FUSE" client would simply do all of this work when the FS is mounted. Then to listen to all traffic from OS_Report(), just run: tail -f srdpfuse/dev/stdout
Of course, it would also expose the complete disc and memory card filesystems, but more importantly, it could also expose non-file resources; all on-board and off-board memory, memory-mapped registers, and even SRDP itself would be represented as files. Interesting to point out that additional clients can be built on top of "SRDP-FUSE": To write to a specific location in RAM, you just fopen() the file, fseeko() to the address, and fwrite() the data! Or, to set a breakpoint: fopen() the SRDP file, fwrite() the SRDP breakpoint command, and fread() the response.
Anyway, that's a great idea that I want to see happen, but it's slightly outside the scope of SRDP, as-is. And I need to adjust the current (horribly incomplete) spec to merge the "stream handling" group into vendor-specific. Thus, "SRDP-FUSE" will implement (an official) vendor-specific group of commands. Probably prefixed with "fs_": fs_open, fs_readdir, fs_read, fs_write, ... Just my strong recommendation.
Before any documentation changes, I need to convert all of it over to Trac. Or, at least rewrite it.
Why am I thinking of this now? Because it's the only practical way to hook file I/O streams, like stdin/out/err. For example on GameCube, the OS_Report() function would be hooked to dump messages to the "stdout" stream (itself exposed to the file system through FUSE as /dev/stdout) and OS_Panic() would dump to the stderr stream (/dev/stderr). So, rather than an SRDP command to initialize these hooks and listen to separate streams, a completely separate "SRDP-FUSE" client would simply do all of this work when the FS is mounted. Then to listen to all traffic from OS_Report(), just run: tail -f srdpfuse/dev/stdout
Of course, it would also expose the complete disc and memory card filesystems, but more importantly, it could also expose non-file resources; all on-board and off-board memory, memory-mapped registers, and even SRDP itself would be represented as files. Interesting to point out that additional clients can be built on top of "SRDP-FUSE": To write to a specific location in RAM, you just fopen() the file, fseeko() to the address, and fwrite() the data! Or, to set a breakpoint: fopen() the SRDP file, fwrite() the SRDP breakpoint command, and fread() the response.
Anyway, that's a great idea that I want to see happen, but it's slightly outside the scope of SRDP, as-is. And I need to adjust the current (horribly incomplete) spec to merge the "stream handling" group into vendor-specific. Thus, "SRDP-FUSE" will implement (an official) vendor-specific group of commands. Probably prefixed with "fs_": fs_open, fs_readdir, fs_read, fs_write, ... Just my strong recommendation.
Before any documentation changes, I need to convert all of it over to Trac. Or, at least rewrite it.
Comment