Hi,
Am Samstag, den 18.03.2017, 07:44 +0100 schrieb Sebastian Sumpf:
Genode has two approaches with regard to drivers: First, we write our own (e.g., AHCI, SD, or ACPI) and second, we port them if we think writing one exceeds our available resources. That being said, the USB driver is ported from Linux and supports UHCI/EHCI/XHCI on x86 and diverse ARM platforms (omap4, exynos5, rpi). USB device driver vise there is hid/nic/storage support. We also have our own storage driver (usb_block) that connects to the USB driver (i.e., the host controller) through our USB session interface. For isochronous USB this sessions the USB host controller drivers would have be to extended to support isochronous transfers.
OK, that confirms my understanding of the task.
A USB device driver (e.g, audio or video) should be written or ported. In the future we want to have all USB device drivers outside of the current USB implementation.
I'm not quite sure how to interpret the last sentence. Does this mean that you want to separate e.g. the HID driver that is currently inside the Linux kernel and have it attach to the Genode USB session interface?
As for additional driver stuff I can think of iMX6 USB and NIC support. AHCI is slowly replaced by NVMe so a NVMHCI implementation would be very welcome and if you are up for a really though one: We are currently implementing our own Intel GPU multiplexer on Broadwell while also having a running port with 3D support enabled. Additionally we are looking into GPU virtualization. In this area there are a lot of things to do or investigate.
The GPU stuff does seem interesting (and challenging), but it also sounds quite hard to quickly get into well enough for writing a solid project proposal if you don't have any prior exposure (like me). NVMHCI sounds like it could be what I was looking for though. I guess the expectation is to have a driver that implements the Block interface similar to the current AHCI driver? Do you have any specific feature requests besides simple read/write? NVMe supports a lot of enhanced stuff (like atomic compare/write and priorities) that cannot be exposed over the current Block interface - question is if there's a need for it.
Regards, Philipp