Stub support for fwrite, fremove, fclose_fd, fopen_with_env_fd

[z3ntu]

Initial feedback welcome, the first commits can be applied in my opinion (see #22), not sure how we want to do the later commits.

For fopen_with_env_fd (or the fopen_fd function that I haven't implemented) I'm honestly not sure what the fd should be or would be used for. It's the same data type as the "fd" for the other functions (e.g. fread) but seems for a different purpose? Not quite sure, but the ADSP is happy enough getting random stub data there.

Also in general, not sure how to handle a mutable version of hexagonrpc, I know rmtfs has a similar issue but there it keeps a copy of the original file in-memory or something, but it's obviously more difficult for a whole file system. Maybe copy the read-only version from /usr/share/qcom to /var/lib/hexagonrpc/ and modify it there only, depending on what's requested?

Log on Milos (Fairphone (Gen. 6)), initializing the sensors far enough to work with iio-sensor-proxy:
output.txt

Fixes #19

[flamingradian]

For fopen_with_env_fd (or the fopen_fd function that I haven't implemented) I'm honestly not sure what the fd should be or would be used for. It's the same data type as the "fd" for the other functions (e.g. fread) but seems for a different purpose? Not quite sure, but the ADSP is happy enough getting random stub data there.

I think it's just the same function with a different data type for the file descriptor, where it's int fd for some functions and others have a apps_std_FILE sin.

Also in general, not sure how to handle a mutable version of hexagonrpc, I know rmtfs has a similar issue but there it keeps a copy of the original file in-memory or something, but it's obviously more difficult for a whole file system. Maybe copy the read-only version from /usr/share/qcom to /var/lib/hexagonrpc/ and modify it there only, depending on what's requested?

I don't even see the use case for writing to any backing files and persistently storing them, beyond offloading the JSON config-to-registry conversions.

[z3ntu]

Where do you suggest we store the files temporarily then? Just in RAM, in /tmp, or some other way?

[lumag]

Where do you suggest we store the files temporarily then? Just in RAM, in /tmp, or some other way?

I'd say, /var/hexagon-dsp or something similar.

[z3ntu]

Do you have an idea how to resolve the situation that we probably want to continue to have the read-only /usr/share/qcom/ but still letting hexagonrpcd delete files? Do we just overlay /var/hexagon-dsp/ on top of /usr/share/qcom/ and not support deleting files that are provided as part of /usr/share/qcom/? So only files hexagonrpcd has created it can delete again? For the start I think that would be a decent solution.

Open file read-only:

1. Check /var/hexagon-dsp/$file
2. If not exists, check /usr/share/qcom/$file

Open file read-write:

1. Check /var/hexagon-dsp/$file
2. If not exists, copy from /usr/share/qcom/$file to /var/hexagon-dsp/$file, open that one.

Delete file:

1. Delete /var/hexagon-dsp/$file if exists. If that doesn't exist, return an error (it may exist in /usr/share/qcom/$file but we just pretend that one doesn't exist for delete use case)

If we wanted to support deleting a file that's originally provided in /usr/share/qcom/ we may either needed to keep track of deleted files so we can pretend they've been deleted. Or we copy the entire /usr/share/qcom/ to /var/hexagon-dsp/ and only work on that, that way we could delete files in that view

[z3ntu]

@lumag ping, since we were talking about this :)

[lumag]

@z3ntu Okay. My rough guess:
I don't think that the firmware is going to write to or unlink the files that we currently have in /usr/share/qcom. If it does, just error out and return -ENOPERM and SCREAM to the logs about it (note: sensors registry file might be different here). For everything else, I think, just open the file at /var/hexagonrpcd. Let's first establish the case of the DSP doing something weird to the rootfs files.