One of the requests before Ion moves out of staging is to split the /dev interface into multiple nodes. The way Ion allocation currently works is by calling ioctls on /dev/ion. This certainly works but requires that Ion have a fairly permissive set of privileges. There’s not an easy1 way to restrict access to certain heaps. Splitting access out into /dev/ion0, /dev/ion1 etc. makes it possible to set Unix and selinux permissions per heap. Benjamin Gaignard has been working on some proposals to make this work.

I decided to give this a boot and run a few tests. Everything came up okay in my buildroot based environment but I didn’t see /dev/ion0, /dev/ion1 on my Android system. Creation of the device nodes is the responsibility of userspace so it wasn’t too surprising to see at least some problems. On most systems, this is handled by some subset of udev, which might be part of systemd or some other init subsystem. Android being Android uses its own setup for device initialization.

My preferred Android board these days is a HiKey development board. Linaro has done a fantastic job of getting support for this board in AOSP so I can work off of AOSP master or one of the branches to do development. By default, AOSP ships a binary kernel module based on whatever branch they are shipping but John Stultz keeps a git tree with a branch that tracks mainline pretty closely. With this setup, I can recompile and test almost any part of the system I want (except for the Mali blobs of course).

The Android init system provides an option to log uevents. This was useful for seeing exactly what was going on. The logs showed the init system probing some typical set of the /sys hierarchy. The Ion nodes weren’t on that list though, so the Android init system wasn’t finding it in /sys. This is what I found in /sys/devices/ on my qemu setup:

# ls /sys/devices/
LNXSYSTM:00  ion0         msr          platform     software     tracepoint
breakpoint   ion1         pci0000:00   pnp0         system       virtual

ion0 and ion1 are present in the /sys hierarchy but not where one might have expected. This was a side-effect of how the underlying devices were set up in the kernel. I’m not very familiar with the device model so I’m hoping to see more feedback on a proper solution. Progress always takes time…

  1. You can do some filtering with seccomp but that’s not the focus here. ↩