GNU Hurd/ open issues/ user-space device drivers

Welcome to... ... the GNU Hurd!

This is a collection of resources concerning user-space device drivers.

Also see device drivers and IO systems. driver glue code.

  1. Issues
    1. IRQs
    2. DMA
    3. I/O Ports
    4. PCI and other buses
    5. Latency of doing RPCs
    6. System Boot
  2. Plan
  3. Documentation
  4. External Projects

Issues

IRQs

  • Can be modeled using RPCs.

  • Security considerations: IRQ sharing.

  • Omega0 paper defines an interface.

  • As is can be read in the Mach 3 Kernel Principles, there is an event object facility in Mach that can be used for having user-space tasks react to IRQs. However, at least in GNU Mach, that code (kern/eventcount.c) doesn't seem functional at all and isn't integrated properly in the kernel.

  • IRC, freenode, #hurd, 2011-07-29

    < antrik> regarding performance of userspace drivers, there is one
  thing that really adds considerable overhead: interrupt
  handling. whether this is relevant very much depends on the hardware
  in question. when sending many small packets over gigabit ethernet,
  it might be noticable; in most other cases it's irrelevant
< youpi> some cards support interrupt coalescin
< youpi> could be supported by DDE too

DMA

  • Security considerations.

    • I/O MMU.

I/O Ports

  • Security considerations.

PCI and other buses

  • Security considerations: sharing.

Latency of doing RPCs

  • GNU Mach is said to have a high overhead when doing RPC calls.

System Boot

IRC, freenode, #hurd, 2011-07-27

< braunr> btw, was there any formulation of the modifications required to
  have disk drivers in userspace ?
< braunr> (which would obviously need something like
  initrd/initramfs/whatever and may also need the root file system not to
  be the first task started)
< braunr> hm actually, we may not need initrd
< braunr> the boot loader could just load more modules
< antrik> braunr: I have described all that in my thesis report... in
  German :-(
< braunr> and the boot scripts could be adjusted to pass around the right
  ports
< Tekk_> braunr: yeah, we could probably load a module that kciks us into
  userspace and starts the disk driver
< braunr> modules are actualy userspace executables
< Tekk_> ah
< Tekk_> so what's the issue?
< Tekk_> oh! I'm thinking the ext2fs server, which is already in userspce
< braunr> change the file systems to tell them which underlying disk driver
  to use
< Tekk_> mhm
< braunr> s/disk/storage/

Plan

  • Examine what other systems are doing.

    • L4

      • Hurd on L4: deva, fabrica

      • DDE

    • Minix 3

  • Start with a simple driver and implement the needed infrastructure (see Issues above) as needed.

Documentation

External Projects