Project handoff

What's missing

LibC functions / system call interception

At present, sunneed is capable of intercepting any C function call. This is the base mechanic that will drive sunneed's supervisor capabilities -- any program running with the sunneed clientlib preloaded can have any of its function calls intercepted by sunneed. Theoretically write is really the only call we care about, since that's fundamentally how programs communicate with devices on Linux. However, more research should be done to ensure we aren't missing anything here; we wouldn't want tenants being able to bypass the entire interception layer by calling functions we haven't implemented.

"Write patterns"

Through intercepting write calls, sunneed has the ability to detect how a tenant is interacting with a device. However, we need some way to determine what that tenant is doing with the device. My idea here is to record a preset pattern of bytes that would be sent to a device. Then, when intercepting writes to that device, sunneed would check if the pattern has been matched. If so, then sunneed knows that some action has been performed on the device. It would use the device's power profile to bill the tenant in question for its power usage.

Device power profiles

Each device that might be connected to a sunneed system is going to have pre-written logic for calculating power usage; trying to calculate the power usage of a device during runtime would be too difficult. Thus, we will need to make a "power profile" for each device. This profile would describe the relationship between specific write patterns and the power used by that device. For example, a servo motor device's power profile would tell sunneed that when certain bytes are written to the servo motor, it will cause the servo motor to move, and thus consume a certain amount of power. Using this power profile, sunneed would then create a new power event with a power consumption equal to that which was described in the power profile.

The power math

We need to actually do something with all this data sunneed is gathering from the intercepted function calls. The proposed system would create so-called "power events" belonging to a tenant any time that tenant performs a power-consuming operation. When a tenant tries to consume power, we sum up all of its recent power events and compare them to the system's remaining battery power; if the ratio of power consumed to power remaining is too high, we deny the tenant's function call.

End-to-end testing

It would be nice to have some test script that spawns the sunneed server along with some test programs that interface with it. sunneed would output results from those programs to a file, and the script would verify that the file has the expected contents. Basically this would just be a way to verify functionality of the entire system on some basic level.

App templates

Using the work from the isochamber branch, we should have a way to package an application into an isochamber environment. The implementation of this would be pretty open-ended, and it's not something we should try to deal with until more parts of the sunneed core have been implemented.