1\section{ATA Messages}
2
3Since this lab project was geared towards designing and implementing a message
4passing interface to disk, only very few message types have been defined to
5showcase the interface. \ac{sata} supports a wider range of devices which can
6benefit from more aspects of the \ac{ata} command set, such as {\tt TRIM} on
7solid state drives. Adding further commands to the flounder-based approach is
8as simple as adding a further message definition.
9
10\section{Integration with the System Knowledge Base}
11
12As we have mainly focused on getting message passing to disk to work, we have
13taken a few shortcuts concerning the integration of our subsystem into
14Barrelfish as a whole. For instance, we do not really use the \acs{skb} to
15uniquely identify the disks attached to an \ac{ahci} controller.  Neither do we
16use the \acs{skb} to store additional data, e.g. serial number and size, of the
17attached disks. Adding that kind of data would simplify discovery of disks and
18acting appropriately, for example automatically mounting a volume or similar.
19
20\section{Handling multiple AHCI controllers at the same time}
21
22Currently our management daemon (see \longref{chap:ahcid}) successfully exits
23from the initialization code as soon as a \ac{ahci} controller has been found.
24It would be prefereable if on systems with multiple controllers attached all of
25these could be used. One consideration in this case would be whether to have
26one management daemon per controller or a global management daemon that
27controls all available \ac{ahci} controllers.
28
29\section{Support for advanced AHCI/SATA features}
30
31Some of the features of \ac{ahci}/\ac{sata} we did not look at are Port
32Multiplication and \ac{ncq}.
33
34However, our system design, including a management daemon that presents each
35port to the rest of the system as a separate entity, makes accomodating
36multiplied ports (multiplying ports is actually done in hardware and the
37\ac{ahci} host controller has a register for each port which contains the port
38multiplication status for that port) relatively easy as the only parts that
39have to be changed are the management daemon and libahci. Also, \ac{ncq} could
40be implemented almost entirely in libahci, if desired.
41
42We also do not handle hotplug of devices. Addition of devices could implemented
43relatively easy by extending ahcid's interrupt handler and performing the
44initialization steps once the link to the device has been established. Removal
45however is more challenging. Outstanding requests have to be completed with an
46error, the user notified and memory resources reclaimed.
47
48\section{Further Controllers}
49
50The modular nature of the Flounder-based approach allows to add additional
51backends for other controllers. Since this lab project only examined
52\ac{ahci}-compliant controllers, support is limited to realtively new
53controllers for \ac{sata}. In reality, there are still a lot of use cases where
54one might have to access \ac{pata}-based devices, such as older CDROM drives.
55Therefore, backends for more chipsets should be developed, most importantly one
56for a widespread \ac{pata} controller such as the \acs{piix} family or the
57\acs{ich} controllers before the introduction of \ac{ahci}.
58