Download Text - Barrelfish

8. Conclusion
Chips replacement.
8.1
Future Work
While the current state of work is already usable and a useful contribution
to Barrelfish, there are still areas for further improvements. Capabilities are
an important data type used in various places in Barrelfish. Right now, we
have no solution to store capability references in Octopus. It would have
been nice to use iterators instead of the current get_names call. This was
not possible due to limitations in ECLi PSe . For performance, there is still
a lot of room for improvements by applying ideas from traditional key–
value stores. However, as long as we rely on the SKB as the underlying
implementation, there will always be a tradeoff between expressiveness and
performance. We currently have no access control for records. This makes it
hard to have a reliable system as every process can modify or delete records.
A possible way would be to use a designated record attribute to encode
access restrictions or use capabilities to restrict record manipulations. To
react to program failures, transient records (i.e., records that are removed
automatically once their creator does no longer exist), would be useful and
allow to build more reliable distributed services for Barrelfish. We were
not able to implement this yet as the current process management does not
allow to monitor dispatchers.
Octopus also opens a lot of possibilities for additions and new functionality in Barrelfish: The ACPI, PCI as well as USB management code can be
adapted for hot plugging support. Kaluga should already be prepared to
catch these events and act appropriately. Device drivers can be modified to
react to changes in hardware by watching records. Octopus can work in a
dynamic environment: Programs can generate records and queries at runtime. It may be worth it to explore how this can be exploited to reconfigure
Barrelfish at runtime instead of having to reboot. Distributed services in Barrelfish can make use of Octopus to solve problems such as leader election
or configuration management. The Prolog language would be a good fit to
extend the current implementation and write algorithms that reason about
the state of records — for example, to detect deadlocks by analyzing lock
records at run time.
54