[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.

[psacal]

Confirmation from SC8280XP (Windows firmware)

I can confirm the method 5 signature (1, 1, 2, 0) on a different
platform — SC8280XP (Huawei MateBook E Go 2023), Windows-compiled
qcslpi8280.mbn.

DSP writes through method 5

My DSP writes "version=1" (9 bytes, not "version=3") through method
5, plus the same "DIR" marker. The stub should probably match both
version prefixes — different firmware revisions write different values.

Two config files control whether method 5 is triggered

This might explain why the issue hasn't surfaced on Android devices:

• sns_reg.conf: Text-format (407 bytes, version=1) from Windows
  DriverStore → DSP initializes normally, never calls method 5.
  Sensors work with empty registry.

• sns_reg.conf: JSON-format (2423 bytes) from Windows DriverData
  runtime copy → DSP enters an abnormal init path, repeatedly calls
  method 5, and also generates oversized messages.

• sns_reg_version: If this file doesn't exist at startup, DSP
  calls method 5 to create it. On Android devices this file is
  pre-populated in the persist partition, so DSP never enters the write
  path. On Windows-firmware devices migrated to Linux, it's absent.

On our platform, using the correct text-format sns_reg.conf +
manually placing sns_reg_version + empty registry avoids all method 5
calls and sensors work immediately. But that's a workaround — the stub
approach in this PR is the right fix.

Sequence when method 5 is NULL (upstream)

stat(sns_reg_version) → ENOENT
  → method 5 fwrite("version=1") → NULL handler → AEE_EUNSUPPORTED
  → method 5 fwrite(temp.json)   → NULL handler → AEE_EUNSUPPORTED
  → retry loop → Broken pipe → DSP crash

Test results with stub fwrite

With a stub analogous to this PR (accept "version=1" and "DIR"
through method 5), all three sensors pass:

• Light: TCS3701, ~408 lux
• Accelerometer: T1000, Z≈9.78
• Gyroscope: T1000, ~0.01 rad/s

Tested with libssc + ssc-bridge → uinput evdev.

Thanks for working on this!

[Drakulix]

The fwrite and fremove implementations from this branch are also enough to get hexagonrpcd working on the Ayaneo Pocket S2 - a SM8650 device - to expose the built-in accelerometer. The current release of hexagonrpcd instead leads to a DSP crash.

[flamingradian]

After !13, the format for method definitions will change. In hexagonrpcd/interface/apps_std.h, the method definitions are declared separately.

In hexagonrpcd/interface/apps_std.c, the arguments are specified by specifying the type instead of specifying the total count:
interface-conversion-example.c

(I would have put the example inline in a click-to-open if I could)

[z3ntu]

(correct link: #13)

Just a sidenote, I don't think I'll be able to work on this in the coming month for example, there's too many other things pending for me to do that have higher priority. But I'd definitely be happy to continue working on this, to get this to a state that can be merged.