A current phone experiment gives Ish/Grease a useful concrete systems workload: make hardware sources look file-like at the shell surface while keeping Android-specific machinery underneath.
The first semantic namespace is deliberately small:
/hardware/sensors/accelerometer/info
/hardware/sensors/accelerometer/sample
/hardware/sensors/accelerometer/events
/hardware/sensors/accelerometer/control
sample produces one x y z measurement and finishes. events remains open and produces measurements. info exposes sensor metadata. control is for explicit settings such as requested sampling period.
Do not make the first implementation depend on mounting a Linux filesystem, FUSE, root, or porting Plan 9. The useful Plan 9 idea is the namespace and uniform read/stream/control model. A command/path adapter can establish the semantics first; a later runtime can present it more literally as files if that remains useful.
Android currently gives at least two relevant implementations of the same source:
- native NDK/libandroid through
ASensorManager/ASensorEventQueue;
- the existing Termux:API Android-service -> command-line bridge.
Lower experimental implementations should also be preserved where feasible: direct Binder to sensorservice, direct sensors HAL, and kernel-facing /dev//sys/IIO/input/vendor nodes. Their value is partly diagnostic: a permission or SELinux denial can establish where an ordinary app process stops. Do not pretend those lower paths work merely because libandroid or Termux:API works.
The shell-facing design question is therefore broader than open(2) or libc: what sources can a program read or wait on together, and what stable object names them? This extends #18. Do not equate a source with an integer POSIX fd unless that is actually the backend contract.
This issue is design/consumer tracking for Ish/Grease, not a claim that the current Oils-derived Grease runtime implements Android sensors. The concrete phone implementation belongs in Ashtray-Archer/utilities-android-phone-user#43. The wider cross-platform Idriç device inventory remains isomorphisms/Idric#85.
A current phone experiment gives Ish/Grease a useful concrete systems workload: make hardware sources look file-like at the shell surface while keeping Android-specific machinery underneath.
The first semantic namespace is deliberately small:
sampleproduces onex y zmeasurement and finishes.eventsremains open and produces measurements.infoexposes sensor metadata.controlis for explicit settings such as requested sampling period.Do not make the first implementation depend on mounting a Linux filesystem, FUSE, root, or porting Plan 9. The useful Plan 9 idea is the namespace and uniform read/stream/control model. A command/path adapter can establish the semantics first; a later runtime can present it more literally as files if that remains useful.
Android currently gives at least two relevant implementations of the same source:
ASensorManager/ASensorEventQueue;Lower experimental implementations should also be preserved where feasible: direct Binder to
sensorservice, direct sensors HAL, and kernel-facing/dev//sys/IIO/input/vendor nodes. Their value is partly diagnostic: a permission or SELinux denial can establish where an ordinary app process stops. Do not pretend those lower paths work merely because libandroid or Termux:API works.The shell-facing design question is therefore broader than
open(2)or libc: what sources can a program read or wait on together, and what stable object names them? This extends #18. Do not equate a source with an integer POSIX fd unless that is actually the backend contract.This issue is design/consumer tracking for Ish/Grease, not a claim that the current Oils-derived Grease runtime implements Android sensors. The concrete phone implementation belongs in Ashtray-Archer/utilities-android-phone-user#43. The wider cross-platform Idriç device inventory remains isomorphisms/Idric#85.