On Release 12.02 we can see a block-driver for AHCI device. I've some question about-it and about general device discovery.
Actualy the AHCI driver is only able to use the first discovered AHCI silicon device upon the PCI bus and use the first port of this device. Because a system can be composed of more than one AHCI device and a AHCI device can be compose of upto 32 port this driver is not fair enough to drive a real system with several disk. Of course this driver is cool for demonstration purpose and enable further development stuff like file systems.
Nevertheless this driver rise to me some questions. I suppose that in future all the AHCI unit (Device and port) will be handle by an instance of this driver. How do you plan to inform one of this driver instance what resource to use (Interface, start-up argument, …). Do you plan to develope a service like udev on linux that will instantiate and configure the devices?
excuse me for my poor english
Sigefroid
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
you're right this driver is currently used for demonstration purposes only. I also discourage using it on real hardware for now, since it might actually break things. Regarding your questions, the AHCI driver is missing a lot of stuff. Most importantly asynchronous block requests, but also the usage of more than one command slot, as well as ATAPI support. I fixed the APIC interrupt issue so, by implementing a ACPI-table parser and thus getting the thing to run on Fisaco.OC and Nova. Discovery, I imagine, might be done by interacting with our device-driver manager service (d3m in 'gems/src/server'), where the AHCI driver might announce block-sessions for each device discovered by scanning the PCI bus. I currently have no intentions to use startup-args. As we plan to use Genode for our daily work (roughly) by the end of this year, I guess a lot of the topics above will be addressed soon. Finally, feel free to participate if you have any spare resources.
Greetings,
Sebastian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello everybody,
On Release 12.02 we can see a block-driver for AHCI device. I've some question about-it and about general device discovery.
Actualy the AHCI driver is only able to use the first discovered AHCI silicon device upon the PCI bus and use the first port of this device. Because a system can be composed of more than one AHCI device and a AHCI device can be compose of upto 32 port this driver is not fair enough to drive a real system with several disk. Of course this driver is cool for demonstration purpose and enable further development stuff like file systems.
Nevertheless this driver rise to me some questions. I suppose that in future all the AHCI unit (Device and port) will be handle by an instance of this driver. How do you plan to inform one of this driver instance what resource to use (Interface, start-up argument, …). Do you plan to develope a service like udev on linux that will instantiate and configure the devices?
excuse me for my poor english
Sigefroid
Hi Sigefroid,
you're right this driver is currently used for demonstration purposes only. I also discourage using it on real hardware for now, since it might actually break things. Regarding your questions, the AHCI driver is missing a lot of stuff. Most importantly asynchronous block requests, but also the usage of more than one command slot, as well as ATAPI support. I fixed the APIC interrupt issue so, by implementing a ACPI-table parser and thus getting the thing to run on Fisaco.OC and Nova. Discovery, I imagine, might be done by interacting with our device-driver manager service (d3m in 'gems/src/server'), where the AHCI driver might announce block-sessions for each device discovered by scanning the PCI bus. I currently have no intentions to use startup-args. As we plan to use Genode for our daily work (roughly) by the end of this year, I guess a lot of the topics above will be addressed soon. Finally, feel free to participate if you have any spare resources.
Greetings,
Sebastian