AROS Arix/Fully random ideas
Currently, AROS hosted tries to maintain its entire memory by itself. Such approach, although it has many advantages, has one drawback. The user is forced to pick some initial amount of memory which AROS will see until it's turned off. Not only this is bad, it does not allow AROS to use all memory available in the system. Moreover, current memory allocation algorithm is rather old (the very same as on the earliest kickstat) and slow. Therefore, following change could be made.
Instead of having one huge chunk of memory for AROS, each single allocation would be wrapped around mmap() system call. The allocated memory would be of anonymous type, shared between the current process and parent processes. The AROS allocation routine could be even extended to provide some special attributes for requested allocation, like RO/RW/X. AROS would be able to allocate much more memory than it can now and would most likely do that faster than it does. Also, the approach could be extended in the future to provide e.g. shared and per task private memory regions and so on.
Drivers touching the hardware
The pci hidd subsystem as implemented in AROS at the moment features special "linux" PCI bus driver, which enables direct use of PCI devices on AROS. Here, no change would be required at the moment. The hardware driver needs to ask the PCI HIDD to map the PCI address range to the virtual address space of the AROS process. Subsequently, the memory or MMIO registers can be accessed by the driver.
Unfortunately, AROS hosted as it is now has no ability to receive any interrupts from the hardware. Here, a kernel module can be written which would expose special device. There, set of IOCTLs could be implemented which would be used to instruct the kernel module which process is awaiting which IRQ. Once requested IRQ would occur, the kernel module would send a signal (any of all the available signals) to the process.
ELF file format