The OpenBSD Foundationbusiness
License: ISC License
Formally, the corporation's objects are to support and further the development, advancement, and maintenance of free software based on the OpenBSD operating system, including the operating system itself and related free software projects.
- ARM SD/MMC driver & controller driver in libsa for OpenBSD Most ARM "System-on-a-chip" devices lack solid firmware for interacting with SD cards which often constitute the main disk. OpenBSD needs a solid SD/MMC stack for interacting with such devices, implemented in its standalone library used at boot time. This would allow for the development of proper device-specific bootloaders, eventually a unified bootloader.
- Asynchronous USB Transfers from Userland This proposal is to enable asynchronous control, bulk, interrupt, and isochronous transfers from userland via the libusb interface in OpenBSD.
- Automating Module Porting I will add the infrastructure necessary to fully automate port creation and update for module ecosystems. Complete support for one ecosystem will be provided by the end of GSoC. The infrastructure will be extensible so that more ecosystems could easily be added.
- Implement KMS driver for Cirrus cards With the current progress done on the graphic stack on many operating systems, the DRM/KMS infrastructure is now used by several BSDs, including OpenBSD. The aim of this project is to write a new KMS driver to handle a Cirrus CLGD 5446 card, and to document the process, to make writing new KMS driver for OpenBSD easier. In addition, the choice of this card will allow usage of KMS drivers when running OpenBSD through QEMU.
- Improving USB userland tools and ioctl(2) This project aim to make the OpenBSD USB userland more consistent, simpler to use and deliver a unified tool to view attached usb device, usbdump(8). Currently, OpenBSD USB userland interface are opaque system call. We don't know what happen without reading the code, especially if they generate I/O. This cause problem with library like libusb which shouldn't cause I/O. Caching static data should fix this problem and suppress the need of system call for reading static data.