A key concept of L4 is that device drivers should be outside the kernel, and not have privileges that allow them to crash the system. This requires support outside the kernel that isn't yet present. I'm writing this to ask some questions about how that will be architected. Once I/O flexpages are in, RMGR will be able to issue access to device space byte by byte. It can connect up interrupts to drivers now. The remaining big security problem is DMA. In most systems, device drivers are given total access to DMA controllers. Could that be avoided, with a trusted process that handles the DMA controllers at the request of the device drivers? I'm going to concentrate on PCI bus issues, since ISA is on the way out and SCSI, USB, and IEEE-1394 devices usually work through a PCI controller. For most devices, DMA is performed by DMA controllers in the core chipset (such as the Intel 82810), not by the peripherals themselves. It's seems to be possible to disable the ability of a PCI device to become a bus master without disabling the ability of the DMA controllers to execute memory and PCI bus cycles, at least with the more modern core chipsets. So it ought to be possible to have a trusted process that handles DMA and deals with the memory mapping issues. This process would be used by device drivers that need DMA. Drivers would not have access to the DMA controllers directly and would be untrusted. There's the related issue of hardware discovery, or "plug and play". Something is needed at startup to discover all the hardware, build the hardware tree, and parcel out hardware resources to drivers. What's planned in that area? Is this consistent with the thinking of the L4/Fiasco/Drops groups? If not, is there something wrong here? John Nagle Animats www.animats.com