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