path: root/service_solahart_jakarta_selatan__082122541663/user-space_device_drivers.mdwn

[[!meta copyright="Copyright © 2009, 2011, 2012, 2013, 2014 Free Software
Foundation, Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

[[!tag open_issue_gnumach open_issue_hurd]]

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

Also see [[device drivers and IO systems]].
[[community/gsoc/project ideas/driver glue code]].

[[!toc levels=2]]


# Open Issues

## IRQs

  * Can be modeled using [[RPC]]s.

  * 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.


### IRC, freenode, #hurd, 2012-08-15

    <carli2> hi. does hurd support mesa?
    <braunr> carli2: software only, but yes
    <carli2> :(
    <carli2> so you did not solve the problem with the CS checkers and GPU DMA
      for microkernels yet, right?
    <braunr> cs = ?
    <carli2> control stream
    <carli2> the data sent to the gpu
    <braunr> no
    <braunr> and to be honest we're not currently trying to
    <carli2> well, a microkernel containing cs checkers for each hardware is
      not a microkernel any more
    <braunr> the problem is having the ability to check
    <braunr> or rather, giving only what's necessary to delegate checking to
      mmus
    <carli2> but maybe the kernel could have a smaller interface like a
      function to check if a memory block is owned by a process
    <braunr> i'm not sure what you refer to
    <carli2> about DMA-capable devices you can send messages to
    <braunr> carli2: dma must be delegated to a trusted server
    <carli2> linux checks the data sent to these devices, parses them and
      checks all pointers if they are in a memory range that the client is
      allowed to read/write from
    <braunr> the client ?
    <carli2> in linux, 3d drivers are in user space, so the kernel side checks
      the pointer sent to the GPU
    <youpi> carli2: mach could do that as well
    <braunr> well, there is a rather large part in kernel space too
    <carli2> so in hurd I trust some drivers to not do evil things?
    <braunr> those in the kernel yes
    <carli2> what does "in the kernel" mean? afaik a microkernel only has
      memory manager and some basic memory sharing and messaging functionality
    <braunr> did you read about the hurd ?
    <braunr> mach is considered an hybrid kernel, not a true microkernel
    <braunr> even with all drivers outside, it's still an hybrid
    <youpi> although we're to move some parts into userlands :)
    <youpi> braunr: ah, why?
    <braunr> youpi: the vm part is too large
    <youpi> ok
    <braunr> the microkernel dogma is no policy inside the kernel
    <braunr> "except scheduling because it's very complicated"
    <braunr> but all modern systems have moved memory management outisde the
      kernel, leaving just the kernel abstraction inside
    <braunr> the adress space kernel abstraction
    <braunr> and the two components required to make it work are what l4re
      calls region mappers (the rough equivalent of our vm_map), which decides
      how to allocate regions in an address space
    <braunr> and the pager, like ours, which are already external
    <carli2> i'm not a OS developer, i mostly develop games, web services and
      sometimes I fix gpu drivers
    <braunr> that was just FYI
    <braunr> but yes, dma must be considered something privileged
    <braunr> and the hurd doesn't have the infrastructure you seem to be
      looking for


## I/O Ports

  * Security considerations.

## PCI and other buses

  * Security considerations: sharing.

## Latency of doing RPCs

  * [[GNU Mach|microkernel/mach/gnumach]] is said to have a high overhead when
    doing RPC calls.


## System Boot

A similar problem is described in
[[community/gsoc/project_ideas/unionfs_boot]], and needs to be implemented.


### 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/


#### IRC, freenode, #hurd, 2012-04-25

    <youpi> btw, remember the initrd thing?
    <youpi> I just came across task.c in libstore/ :)


#### IRC, freenode, #hurd, 2013-06-24

    <youpi> we added a new initrd command to gnumach, to expose a new mach
      device, which ext2fs can open and unzip
    <youpi> we consider replacing that with simply putting the data in a dead
      process
    <youpi> s/process/task
    <youpi> and let ext2fs read data from the task, and kill it when done
    <teythoon> ok
    <youpi> alternatively, tmps would work with an initial .tar.gz payload
    <youpi> that would be best for memory usage
    <youpi> tmpfs*
    <teythoon> can't we replace the initrd concept with sub/neighbourhood?
    <youpi> setting up tmpfs with an initial payload could be done with a
      bootstrap subhurd
    <teythoon> yes
    <youpi> but it seems to me that having tmpfs being able to have an initial
      payload is interesting
    <teythoon> is there any advantage of the tmpfs translator prefilled with a
      tarball over ext2fs with copy & bunzip?
    <youpi> memory usage
    <youpi> ext2fs with copy&bunzip takes memory for zeroes
    <youpi> and we have to forecast how much data might be stored
    <youpi> (if writable)
    <teythoon> ah sure
    <teythoon> but why would it have to be in the tmpfs translator? I why not
      start the translator and have tar extract stuff there?
    <teythoon> with the livecd I had trouble replacing the root translator, but
      when using subhurds that shouldn't be a prwoblem at all
    <youpi> I don't have a real opinion on this
    <youpi> except that people don't usually like initrd :)
    <braunr> 12:43 < teythoon> but why would it have to be in the tmpfs
      translator? I why not start the translator and have tar extract stuff
      there?
    <braunr> that sounds an awful lot like an initramfs
    <teythoon> yes, exactly, without actually having an initramfs of course
    <braunr> yep
    <braunr> i actually prefer that way too
    <teythoon> a system on a r/o isofs cannot do much, but it can do this
    <braunr> on the other hand, i wouldn't spend much time on a virtio disk
      driver for now
    <braunr> the hurd as it is can't boot on a device that isn't managed by the
      kernel
    <braunr> we'd need to change the boot protocol

[[virtio]].


#### IRC, freenode, #hurd, 2013-06-28

    <teythoon> I'm tempted to redo a livecd, simpler and without the initrd
      hack that youpi used for d-i
    <braunr> initrd hack ?
    <braunr> you mean more a la initramfs then ?
    <teythoon> no, I thought about using a r/o isofs translator, but instead of
      fixing that one up with a r/w overlay and lot's of firmlinks like I used
      to, it would just start an ext2fs translator with copy on an image stored
      on the iso and start a subhurd
    <braunr> why a subhurd ?
    <teythoon> neighbourhurd even
    <teythoon> b/c back in the days I had trouble replacing /
    <braunr> yes, that's hard
    <teythoon> subhurd would take of that for free
    <braunr> are you sure ?
    <teythoon> somewhat
    <braunr> i'm not, but this requires thorough thinking
    <braunr> and i'm not there yet
    <teythoon> y would it not?
    <teythoon> just start a subhurd and let that one take over the console and
      let the user and d-i play nicely in that environment
    <teythoon> no hacks involved
    <braunr> because it would require sharing things between the two system
      instances, and that's not easy
    <teythoon> no but the bootstrap system does nothing after launching the
      subhurd
    <teythoon> I mean yes, technically true, but why would it be hard to share
      with someone who does nothing?
    <braunr> the context isn't well defined enough to clearly state anything
    <braunr> if you don't use the resources of the first hurd, that's ok
    <braunr> otherwise, it may be easy or not, i don't know yet
    <teythoon> you think it's worth a shot and see what issues crop up?
    <braunr> sure
    <braunr> definitely
    <teythoon> it doesn't sound complicated at all
    <braunr> it's easy enough to the point we see something goes wrong or works
      completely
    <braunr> so worth testin
    <teythoon> cool :)


#### IRC, freenode, #hurd, 2014-02-10

    <teythoon> braunr: i have a question wrt memory allocation in gnumach
    <teythoon> i made a live cd with a rather large ramdisk
    <teythoon> it works fine in qemu, when i tried it on a real machine it
      failed to allocate the buffer for the ramdisk
    <teythoon> i was wondering why
    <teythoon> i believe the function that failed was kmem_alloc trying to
      allocate 64 megabytes
    <braunr> teythoon: how much memory on the real machine ?
    <teythoon> 4 gigs
    <braunr> so 1.8G
    <teythoon> yes
    <braunr> does it fail systematically ?
    <teythoon> but surely enough
    <teythoon> uh, i must admit i only tried it once
    <braunr> it's likely a 64M kernel allocation would fail
    <braunr> the kmem_map is 128M wide iirc
    <braunr> and likely fragmented
    <braunr> it doesn't take much to prevent a 64M contiguous virtual area
    <teythoon> i see
    <braunr> i suggest you try my last gnumach patch
    <teythoon> hm
    <teythoon> surely there is a way to make this more robust, like using a
      different map for the allocation ?
    <braunr> the more you give to the kernel, the less you have for userspace
    <braunr> merging maps together was actually a goal
    <braunr> the kernel should never try to allocate such a large region
    <braunr> can you trace the origin of the allocation request ?
    <teythoon> i'm pretty sure it is for the ram disk
    <braunr> makes sense but still, it's huge
    <teythoon> well...
    <braunr> the ram disk should behave as any other mapping, i.e. pages should
      be mapped in on demand
    <teythoon> right, so the implementation could be improved ?
    <braunr> we need to understand why the kernel makes such big requests first
    <teythoon> oh ? i thought i asked it to do so
    <braunr> ?
    <teythoon> for the ram disk
    <braunr> normally, i would expect this to translate to the creation of a
      64M anonymous memory vm object
    <braunr> the kernel would then fill that object with zeroed pages on demand
      (on page fault)
    <braunr> at no time would there be a single 64M congituous kernel memory
      allocation
    <braunr> such big allocations are a sign of a serious bug
    <braunr> for reference, linux (which is even more demanding because
      physical memory is directly mapped in kernel space) allows at most 4M
      contiguous blocks on most architectures
    <braunr> on my systems, the largest kernel allocation is actually 128k
    <braunr> and there are only two such allocations
    <braunr> teythoon: i need you to reproduce it so we understand what happens
      better
    <teythoon> braunr: currently the ramdisk implementation kmem_allocs the
      buffer in the kernel_map
    <braunr> hum
    <braunr> did you add this code ?
    <teythoon> no
    <braunr> where is it ?
    <teythoon> debian/patches
    <braunr> ugh
    <teythoon> heh
    <braunr> ok, don't expect that to scale
    <braunr> it's a quick and dirty hack
    <braunr> teythoon: why not use tmpfs ?
    <teythoon> i use it as root filesystem
    <braunr> :/
    <braunr> ok so
    <braunr> update on what i said before
    <braunr> kmem_map is exclusively used for kernel object (slab) allocations
    <braunr> kmem_map is a submap of kernel_map
    <braunr> which is 192M on i386
    <braunr> so a 64M allocation can't work at all
    <braunr> it would work on xen, where the kernel map is 224M large
    <braunr> teythoon: do you use xen ?
    <teythoon> ok, thanks for the pointers :)
    <teythoon> i don't use xen
    <braunr> then i can't explain how it worked in your virtual machine
    <braunr> unless the size was smaller
    <teythoon> i'll look into improving the ramdisk patch if time permits
    <teythoon> no it wasnt
    <braunr> :/
    <teythoon> and it works reliably in qemu
    <braunr> that's very strange
    <braunr> unless the kernel allocates nothing at all inside kernel_map on
      qemu


##### IRC, freenode, #hurd, 2014-02-11

    <teythoon> braunr: http://paste.debian.net/81339/
    <braunr> teythoon: oO ?
    <braunr> teythoon: you can't allocate memory from a non kernel map
    <braunr> what you're doing here is that you create a separate, non-kernel
      address space, that overlaps kernel memory, and allocate from that area
    <braunr> it's like having two overlapping heaps and allocating from them
    <teythoon> braunr: i do?  o_O
    <teythoon> so i need to map it instead ?
    <braunr> teythoon: what do you want to do ?
    <teythoon> i'm currently reading up on the vm system, any pointers ?
    <braunr> teythoon: but what do you want to achieve here ?
    <braunr> 12:24 < teythoon> so i need to map it instead ?
    <teythoon> i'm trying to do what you said the other day, create a different
      map to back the ramdisk
    <braunr> no
    <teythoon> no ?
    <braunr> i said an object, not a map
    <braunr> but it means a complete rework
    <teythoon> ok
    <teythoon> i'll head back into hurd-land then, though i'd love to see this
      done properly
    <braunr> teythoon: what you want basically is tmpfs as a rootfs right ?
    <teythoon> sure
    <teythoon> i'd need a way to populate it though
    <braunr> how is it done currently ?
    <teythoon> grub loads an ext2 image, then it's copied into the ramdisk
      device, and used by the root translator
    <braunr> how is it copied ?
    <braunr> what makes use of the kernel ramdisk ?
    <teythoon> in ramdisk_create, currently via memcpy
    <teythoon> the ext2fs translator that provides /
    <braunr> ah so it's a kernel device like hd0 ?
    <teythoon> yes
    <braunr> hm ok
    <braunr> then you could create an anonymous memory object in the kernel,
      and map read/write requests to object operations
    <braunr> the object must not be mapped in the kernel though, only temporary
      on reads/writes
    <teythoon> right
    <teythoon> so i'd not use memcpy, but one of the mach functions that copy
      stuff to memory objects ?
    <braunr> i'm not sure
    <braunr> you could simply map the object, memcpy to/from it, and unmap it
    <teythoon> what documentation should i read ?
    <braunr> vm/vm_map.h for one
    <teythoon> i can only find stuff describing the kernel interface to
      userspace
    <braunr> vm/vm_kern.h may help
    <braunr> copyinmap and copyoutmap maybe
    <braunr> hm no
    <teythoon> vm_map.h isn't overly verbose :(
    <braunr> vm_map_enter/vm_map_remove
    <teythoon> ah, i actually tried vm_map_enter
    <braunr> look at the .c files, functions are described there
    <teythoon> that leads to funny results
    <braunr> vm_map_enter == mmap basically
    <braunr> and vm_object.h
    <teythoon> panic: kernel thread accessed user space!
    <braunr> heh :)
    <teythoon> right, i hoped vm_map_enter to be the in-kernel equivalent of
      vm_map

    <teythoon> braunr: uh, it worked
    <braunr> teythoon: ?
    <teythoon> weird
    <teythoon> :)
    <braunr> teythoon: what's happening ?
    <teythoon> i refined the ramdisk patch, and it seems to work
    <teythoon> not sure if i got it right though, i'll paste the patch
    <braunr> yes please
    <teythoon> http://paste.debian.net/81376/
    <braunr> no it can't work either
    <teythoon> :/
    <braunr> you can't map the complete object
    <teythoon> (amusingly it does)
    <braunr> you have to temporarily map the pages you want to access
    <braunr> it does for the same obscure reason the previous code worked on
      qemu
    <teythoon> ok, i think i see
    <braunr> increase the size a lot more
    <braunr> like 512M
    <braunr> and see
    <braunr> you could also use the kernel debugger to print the kernel map
      before and after mapping
    <teythoon> how ?
    <braunr> hm
    <braunr> see show task
    <braunr> maybe you can call the in kernel function directly with the kernel
      map as argument
    <teythoon> which one ?
    <braunr> the one for "show task"
    <braunr> hm no it shows threads, show map
    <braunr> and show map crashes on darnassus ..
    <teythoon> here as well
    <braunr> ugh
    <braunr> personally i'd use something like vm_map_info in x15
    <braunr> but you may not want to waste time with that
    <braunr> try with a bigger size and see what it does, should be quick and
      simple enough
    <teythoon> right
    <teythoon> braunr: ok, you were right, mapping the entire object fails if
      it is too big
    <braunr> teythoon: fyi, kmem_alloc and vm_map have some common code, namely
      the allocation of an virtual area inside a vm_map
    <braunr> kmem_alloc requires a kernel map (kernel_map or a submap) whereas
      vm_map can operate on any map
    <braunr> what differs is the backing store
    <teythoon> braunr: i believe i want to use vm_object_copy_slowly to create
      and populate the vm object
    <teythoon> for that, i'd need a source vm_object
    <teythoon> the data is provided as a multiboot_module
    <braunr> kmem_alloc backs the virtual range with wired down physical memory
    <braunr> whereas vm_map maps part of an object that is usually pageable
    <teythoon> i see
    <braunr> and you probably want your object to be pageable here
    <teythoon> yes :)
    <braunr> yes object copy functions could work
    <braunr> let me check
    <teythoon> what would i specify as source object ?
    <braunr> let's assume a device write
    <braunr> the source object would be where the source data is
    <braunr> e.g. the data provided by the user
    <teythoon> yes
    <teythoon> trouble is, i'm not sure what the source is
    <braunr> it looks a bit complicated yes
    <teythoon> i mean the boot loader put it into memory, not sure what mach
      makes of that
    <braunr> i guess there already are device functions that look up the object
      from the given address
    <braunr> it's anonymous memory
    <braunr> but that's not the problem here
    <teythoon> so i need to create a memory object for that ?
    <braunr> you probably don't want to populate your ramdisk from the kernel
    <teythoon> wire it down to the physical memory ?
    <braunr> don't bother with the wire property
    <teythoon> oh ?
    <braunr> if it can't be paged out, it won't be
    <teythoon> ah, that's not what i meant
    <braunr> you probably want ext2fs to populate it, or another task loaded by
      the boot loader
    <teythoon> interesting idea
    <braunr> and then, this task will have a memory object somewhere
    <braunr> imagine a task which sole purpose is to embedd an archive to
      extract into the ramdisk
    <teythoon> sweet, my thoughts exactly :)
    <braunr> the data section of a program will be backed by an anonymous
      memory object
    <braunr> the problem is the interface
    <braunr> the device interface passes addresses and sizes
    <braunr> you need to look up the object from that
    <braunr> but i guess there is already code doing that in the device code
      somewhere
    <braunr> teythoon: vm_object_copy_slowly seems to create a new object
    <braunr> that's not exactly what we want either
    <teythoon> why not ?
    <braunr> again, let's assume a device_write scenario
    <teythoon> ah
    <braunr> you want to populate the ramdisk, which is merely one object
    <braunr> not a new object
    <teythoon> yes
    <braunr> teythoon: i suggest using vm_page_alloc and vm_page_copy
    <braunr> and vm_page_lookup
    <braunr> teythoon: perhaps vm_fault_page too
    <braunr> although you might want wired pages initially
    <braunr> teythoon: but i guess you see what i mean when i say it needs to
      be reworked
    <teythoon> i do
    <teythoon> braunr: aww, screw that, using a tmpfs is much nicer anyway
    <teythoon> the ramdisk strikes again ...
    <braunr> teythoon: :)
    <braunr> teythoon: an extremely simple solution would be to enlarge the
      kernel map
    <braunr> this would reduce the userspace max size to ~1.7G but allow ~64M
      ramdisks
    <teythoon> nah
    <braunr> or we could reduce the kmem_map
    <braunr> i think i'll do that anyway
    <braunr> the slab allocator rarely uses more than 50-60M
    <braunr> and the 64M remaining area in kernel_map can quickly get
      fragmented
    <teythoon> braunr: using a tmpfs as the root translator won't be straight
      forward either ... damn the early boostrapping stuff ...
    <braunr> yes ..
    <teythoon> that's one of the downsides of the vfs-as-namespace approach
    <braunr> i'm not sure
    <braunr> it could be simplified
    <teythoon> hm
    <braunr> it could even use a temporary name server to avoid dependencies
    <teythoon> indeed
    <teythoon> there's even still the slot for that somewhere
    <antrik> braunr: hm... I have a vague recollection that the fixed-sized
      kmem-map was supposed to be gone with the introduction of the new
      allocator?...
    <braunr> antrik: the kalloc_map and kmem_map were merged
    <braunr> we could directly use kernel_map but we may still want to isolate
      it to avoid fragmentation

See also the discussion on [[gnumach_memory_management]], *IRC, freenode,
\#hurd, 2013-01-06*, *IRC, freenode, #hurd, 2014-02-11* (`KENTRY_DATA_SIZE`).


### IRC, freenode, #hurd, 2012-07-17

    <bddebian> OK, here is a stupid question  I have always had.  If you move
      PCI and disk drivers in to userspace, how do do initial bootstrap to get
      the system booting?
    <braunr> that's hard
    <braunr> basically you make the boot loader load all the components you
      need in ram
    <braunr> then you make it give each component something (ports) so they can
      communicate


### IRC, freenode, #hurd, 2012-08-12

    <antrik> braunr: so, about booting with userspace disk drivers
    <antrik> after rereading the chapter in my thesis, I see that there aren't
      really all than many interesting options...
    <antrik> I pondered some variants involving a temporary boot filesystem
      with handoff to the real root FS; but ultimately concluded with another
      option that is slightly less elegant but probably gets a much better
      usefulness/complexity ratio:
    <antrik> just start the root filesystem as the first process as we used to;
      only hack it so that initially it doesn't try to access the disk, but
      instead gets the files from GRUB
    <antrik> once the disk driver is operational, we flip a switch, and the
      root filesystem starts reading stuff from disk normally
    <antrik> transparently for all other processes
    <bddebian> How does grub access the disk without drivers?
    <antrik> bddebian: GRUB obviously has its own drivers... that's how it
      loads the kernel and modules
    <antrik> bddebian: basically, it would have to load additional modules for
      all the components necessary to get the Hurd disk driver going
    <bddebian> Right, why wouldn't that be possible?
    <antrik> (I have some more crazy ideas too -- but these are mostly
      orthogonal :-) )
    <antrik> ?
    <antrik> I'm describing this because I'm pretty sure it *is* possible :-)
    <bddebian> That grub loads the kernel and whatever server/module gets
      access to the disk
    <antrik> not sure what you mean
    <bddebian> Well as usual I probably don't know the proper terminology but
      why could grub load gnumach and the hurd "disk server" that contains the
      userspace drivers?
    <antrik> disk server?
    <bddebian> Oh FFS whatever contains the disk drivers :)
    <bddebian> diskdde, whatever :)
    <antrik> actually, I never liked the idea of having a big driver blob very
      much... ideally each driver should have it's own file
    <antrik> but that's admittedly beside the point :-)
    <antrik> its
    <antrik> so to restate: in addition to gnumach, ext2fs.static, and ld.so,
      in the new scenario GRUB will also load exec, the disk driver, any
      libraries these two depend upon, and any additional infrastructure
      involved in getting the disk driver running (for automatic probing or
      whatever)
    <antrik> probably some other Hurd core servers too, so we can have a more
      complete POSIX environment for the disk driver to run in
    <bddebian> There ya go :)
    <antrik> the interesting part is modifying ext2fs so it will access only
      the GRUB-provided files, until it is told that it's OK now to access the
      real disk
    <antrik> (and the mechanism how ext2 actually gets at the GRUB-provided
      files)
    <bddebian> Or write some new really small ext2fs? :)
    <antrik> ?
    <bddebian> I'm just talking out my butt.  Something temporary that gets
      disposed of when the real disk is available :)
    <antrik> well, I mentioned above that I considered some handoff
      schemes... but they would probably be more complex to implement than
      doing the switchover internally in ext2
    <bddebian> Ah
    <bddebian> boot up in a ramdisk? :)
    <antrik> (and the temporary FS would *not* be an ext2 obviously, but rather
      some special ramdisk-like filesystem operating from GRUB-loaded files...)
    <antrik> again, that would require a complicated handoff-scheme
    <bddebian> Bah, what do I know? :)
    <antrik> (well, you could of course go with a trivial chroot()... but that
      would be ugly and inefficient, as the initial processes would still run
      from the ramdisk)
    <bddebian> Aren't most things running in memory initially anyway?  At what
      point must it have access to the real disk?
    <braunr> antrik: but doesn't that require that disk drivers be statically
      linked ?
    <braunr> and having all disk drivers in separate tasks (which is what we
      prefer to blobs as you put it) seems to pretty much forbid using static
      linking
    <braunr> hm actually, i don't see how any solution could work without
      static linking, as it would create a recursion
    <braunr> and the only one required is the one used by the root file system
    <braunr> others can be run from the dynamically linked version
    <braunr> antrik: i agree, it's a good approach, requiring only a slightly
      more complicated boot script/sequence
    <antrik> bddebian: at some point we have to access the real disk so we
      don't have to work exclusively with stuff loaded by grub... but there is
      no specific point where it *has* to happen. generally speaking, the
      sooner the better
    <antrik> braunr: why wouldn't that work with a dynamically linked disk
      driver? we only need to make sure all required libraries are loaded by
      grub too
    <braunr> antrik: i have a problem with that approach :p
    <braunr> antrik: it would probably require a reboot when those libraries
      are upgraded, wouldn't it ?
    <antrik> I'd actually wish we could run with a dynamically linked ext2fs as
      well... but that would require a separated boot filesystem and some kind
      of handoff approach, which would be much more complicated I fear...
    <braunr> and if a driver is restarted, would it use those libraries too ?
      and if so, how to find them ?
    <braunr> but how can you run a dynamically linked root file system ?
    <braunr> unless the libraries it uses are provided by something else, as
      you said
    <antrik> braunr: well, if you upgrade the libraries, *and* want the disk
      driver to use the upgraded libraries, you are obviously in a tricky
      situation ;-)
    <braunr> yes
    <antrik> perhaps you could tell ext2 to preload the new libraries before
      restarting the disk driver...
    <antrik> but that's a minor quibble anyways IMHO
    <braunr> but that case isn't that important actually, since upgrading these
      libraries usually means we're upgrading the system, which can imply a
      reoobt
    <braunr> i don't think it is
    <braunr> it looks very complicated to me
    <braunr> think of restart as after a crash :p
    <braunr> you can't preload stuff in that case
    <antrik> uh? I don't see anything particularily complicated. but my point
      was more that it's not a big thing if that's not implemented IMHO
    <braunr> right
    <braunr> it's not that important
    <braunr> but i still think statically linking is better
    <braunr> although i'm not sure about some details
    <antrik> oh, you mean how to make the root filesystem use new libraries
      without a reboot? that would be tricky indeed... but this is not possible
      right now either, so that's not a regression
    <braunr> i assume that, when statically linking, only the .o providing the
      required symbols are included, right ?
    <antrik> making the root filesystem restartable is a whole different epic
      story ;-)
    <braunr> antrik: not the root file system, but the disk driver
    <braunr> but i guess it's the same
    <antrik> no, it's not
    <braunr> ah
    <antrik> for the disk driver it's really not that hard I believe
    <antrik> still some extra effort, but definitely doable
    <braunr> with the preload you mentioned
    <antrik> yes
    <braunr> i see
    <braunr> i don't think it's worth the trouble actually
    <braunr> statically linking looks way simpler and should make for smaller
      binaries than if libraries were loaded by grub
    <antrik> no, I really don't want statically linked disk drivers
    <braunr> why ?
    <antrik> again, I'd prefer even ext2fs to be dynamic -- only that would be
      much more complicated
    <braunr> the point of dynamically linking is sharing
    <antrik> while dynamic disk drivers do not require any extra effort beyond
      loading the libraries with grub
    <braunr> but if it means sharing big files that are seldom used (i assume
      there is a lot of code that simply isn't used by hurd servers), i don't
      see the point
    <antrik> right. and with the approach I proposed that will work just as it
      should
    <antrik> err... what big files?
    <braunr> glibc ?
    <antrik> I don't get your point
    <antrik> you prefer statically linking everything needed before the disk
      driver runs (which BTW is much more than only the disk driver itself) to
      using normal shared libraries like the rest of the system?...
    <braunr> it's not "like the rest of the system"
    <braunr> the libraries loaded by grub wouldn't be back by the ext2fs server
    <braunr> they would be wired in memory
    <braunr> you'd have two copies of them, the one loaded by grub, and the one
      shared by normal executables
    <antrik> no
    <braunr> i prefer static linking because, if done correctly, the combined
      size of the root file system and the disk driver should be smaller than
      that of the rootfs+disk driver and libraries loaded by grub
    <antrik> apparently I was not quite clear how my approach would work :-(
    <braunr> probably not
    <antrik> (preventing that is actually the reason why I do *not* want as
      simple boot filesystem+chroot approach)
    <braunr> and initramfs can be easily freed after init
    <braunr> an*
    <braunr> it wouldn't be a chroot but something a bit more involved like
      switch_root in linux
    <antrik> not if various servers use files provided by that init filesystem
    <antrik> yes, that's the complex handoff I'm talking about
    <braunr> yes
    <braunr> that's one approach
    <antrik> as I said, that would be a quite elegant approach (allowing a
      dynamically linked ext2); but it would be much more complicated to
      implement I believe
    <braunr> how would it allow a dynamically linked ext2 ?
    <braunr> how can the root file system be linked with code backed by itself
      ?
    <braunr> unless it requires wiring all its memory ?
    <antrik> it would be loaded from the init filesystem before the handoff
    <braunr> init sn't the problem here
    <braunr> i understand how it would boot
    <braunr> but then, you need to make sure the root fs is never used to
      service page faults on its own address space
    <braunr> or any address space it depends on, like the disk driver
    <braunr> so this basically requires wiring all the system libraries, glibc
      included
    <braunr> why not
    <antrik> ah. yes, that's something I covered in a separate section in my
      thesis ;-)
    <braunr> eh :)
    <antrik> we have to do that anyways, if we want *any* dynamically linked
      components (such as the disk driver) in the paging path
    <braunr> yes
    <braunr> and it should make swapping more reliable too
    <antrik> so that adds a couple MiB of wired memory... I guess we will just
      have to live with that
    <braunr> yes it seems acceptable
    <braunr> thanks
    <antrik> (it is actually one reason why I want to avoid static linking as
      much as possible... so at least we have to wire these libraries only
      *once*)
    <antrik> anyways, back to my "simpler" approach
    <antrik> the idea is that a (static) ext2fs would still be the first task
      running, and immediately able to serve filesystem access requests -- only
      it would serve these requests from files preloaded by GRUB rather than
      the actual disk driver
    <braunr> i understand now
    <antrik> until a switch is flipped telling it that now the disk driver (and
      anything it depends upon) is operational
    <braunr> you still need to make sure all this is wired
    <antrik> yes
    <antrik> that's orthogonal
    <antrik> which is why I have a separate section about it :-)
    <braunr> what was the relation with ggi ?
    <antrik> none strictly speaking
    <braunr> i'll rephrase it: how did it end up in your thesis ?
    <antrik> I just covered all aspects of userspace drivers in one of the
      "introduction" sections of my thesis
    <braunr> ok
    <antrik> before going into specifics of KGI
    <antrik> (and throwing in along the way that most of the issues described
      do not matter for KGI ;-) )
    <braunr> hehe
    <braunr> i'm wondering, do we have mlockall on the hurd ? it seems not
    <braunr> that's something deeply missing in mach
    <antrik> well, bootstrap in general *is* actually relevant for KGI as well,
      because of console messages during boot... but the filesystem bootstrap
      is mostly irrelevant there ;-)
    <antrik> braunr: oh? that's a problem then... I just assumed we have it
    <braunr> well, it's possible to implement MCL_CURRENT, but not MCL_FUTURE
    <braunr> or at least, it would be a bit difficult
    <braunr> every allocation would need to be aware of that property
    <braunr> it's better to have it managed by the vm system
    <braunr> mach-defpager has its own version of vm_allocate for that
    <antrik> braunr: I don't think we care about MCL_FUTURE here
    <antrik> hm, wait... MCL_CURRENT is fine for code, but it might indeed be a
      problem for dynamically allocated memory :-(
    <braunr> yes


# 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.

      * <http://savannah.nongnu.org/projects/user-drivers/>

        Some (unfinished?) code written by Robert Millan in 2003: PC keyboard
        and parallel port drivers, using `libtrivfs`.


## I/O Server

### IRC, freenode, #hurd, 2012-08-10

    <braunr> usually you'd have an I/O server, and serveral device drivers
      using it
    <bddebian> Well maybe that's my question.  Should there be unique servers
      for say ISA, PCI, etc or could all of that be served by one "server"?
    <braunr> forget about ISA
    <bddebian> How?  Oh because the ISA bus is now served via a PCI bridge?
    <braunr> the I/O server would merely be there to help device drivers map
      only what they require, and avoid conflicts
    <braunr> because it's a relic of the past :p
    <braunr> and because it requires too high privileges
    <bddebian> But still exists in several PCs :)
    <braunr> so usually, you'd directly ask the kernel for the I/O ports you
      need
    <mel-> so do floppy drives
    <mel-> :)
    <braunr> if i'm right, even the l4 guys do it that way
    <braunr> he's right, some devices are still considered ISA
    <bddebian> But that is where my confusion lies.  Something has to figure
      out what/where those I/O ports are
    <braunr> and that's why i tell you to forget about it
    <braunr> ISA has both statically allocated ports (the historical ones) and
      others usually detected through PnP, when it works
    <braunr> PCI is much cleaner, and memory mapped I/O is both better and much
      more popular currently
    <bddebian> So let's say I have a PCI SCSI card.  I need some device driver
      to know how to talk to that, right?
    <bddebian> something is going to enumerate all the PCI devices and map them
      to and address space
    <braunr> bddebian: that would be the I/O server
    <braunr> we'll call it the PCI server
    <bddebian> OK, that is where I am headed.  What if everything isn't PCI?
      Is the "I/O server" generic enough?
    <youpi> nowadays everything is PCI
    <bddebian> So we are completely ignoring legacy hardware?
    <braunr> we could have separate servers using a shared library that would
      provide allocation routines like resource maps
    <braunr> yes
    <youpi> for what is not, the translator just needs to be run as root
    <youpi> to get i/o perm from the kernel
    <braunr> the idea for projects like ours, where the user base is very small
      is: don't implement what you can't test
    <youpi> bddebian: legacy can not be supported in a nice way, so for them we
      can just afford a bad solution
    <youpi> i.e. leave the driver in kernel
    <braunr> right
    <youpi> e.g. the keyboard
    <bddebian> Well what if I have a USB keyboard? :-P
    <braunr> that's a different matter
    <youpi> USB keyboard is not legacy hardware
    <youpi> it's usb
    <youpi> which can be enumerated like pci
    <braunr> and USB uses PCI
    <youpi> and pci could be on usb :)
    <braunr> so it's just a separate stack on top of the PCI server
    <bddebian> Sure so would SCSI in my example above but is still a seperate
      bus
    <braunr> netbsd has a very nice way of attaching drivers to buses
    <youpi> bddebian: also, yes, and it can be enumerated
    <bddebian> Which was my original question.  This magic I/O server handles
      all of the buses?
    <youpi> no, just PCI, and then you'd have other servers for other busses
    <braunr> i didn't mean that there would be *one* I/O server instance
    <bddebian> So then it isn't a generic I/O server is it?
    <bddebian> Ahhhh
    <youpi> that way you can even put scsi over ppp or other crazy things
    <braunr> it's more of an idea
    <braunr> there would probably be a generic interface for basic stuff
    <braunr> and i assume it could be augmented with specific (e.g. USB)
      interfaces for servers that need more detailed communication
    <braunr> (well, i'm pretty sure of it)
    <bddebian> So the I/O server generalizes all functions, say read and write,
      and then the PCI, USB, SCIS, whatever servers are contacted by it?
    <braunr> no, not read and write
    <braunr> resource allocation rather
    <youpi> and enumeration
    <braunr> probing perhaps
    <braunr> bddebian: the goal of the I/O server is to make it possible for
      device drivers to access the resources they need without a chance to
      interfere with other device drivers
    <braunr> (at least, that's one of the goals)
    <braunr> so a driver would request the bus space matching the device(s) and
      obtain that through memory mapping
    <bddebian> Shouldn't that be in the "global address space"?  SOrry if I am
      using the wrong terminology
    <youpi> well, the i/o server should also trigger the start of that driver
    <youpi> bddebian: address space is not a matter for drivers
    <braunr> bddebian: i'm not sure what you think of with "global address
      space"
    <youpi> bddebian: it's just a matter for the pci enumerator when (and if)
      it places the BARs in physical address space
    <youpi> drivers merely request mapping that, they don't need to know about
      actual physical addresses
    <braunr> i'm almost sure you lost him at BARs
    <braunr> :(
    <braunr> youpi: that's what i meant with probing actually
    <bddebian> Actually I know BARs I have been reading on PCI :)
    <bddebian> I suppose physicall address space is more what I meant when I
      used "global address space"
    <braunr> i see
    <youpi> bddebian: probably, yes


# Documentation

  * [An Architecture for Device Drivers Executing as User-Level
    Tasks](http://portal.acm.org/citation.cfm?id=665603), 1993, David B. Golub,
    Guy G. Sotomayor, Freeman L. Rawson, III

  * [Performance Measurements of the Multimedia Testbed on Mach 3.0: Experience
    Writing Real-Time Device Drivers, Servers, and
    Applications](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.40.8685),
    1993, Roger B. Dannenberg, David B. Anderson, Tom Neuendorffer, Dean
    Rubine, Jim Zelenka

  * [User Level IPC and Device Management in the Raven
    Kernel](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.57.3733),
    1993, D. Stuart Ritchie, Gerald W. Neufeld

  * [Creating User-Mode Device Drivers with a
    Proxy](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.26.3055),
    1997, Galen C. Hunt

  * [The APIC Approach to High Performance Network Interface Design: Protected
    DMA and Other
    Techniques](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.56.1198),
    1997, Zubin D. Dittia, Guru M. Parulkar, Jerome R. Cox, Jr.

  * [The Fluke Device Driver
    Framework](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.4.7927),
    1999, Kevin Thomas Van Maren

  * [Omega0: A portable interface to interrupt hardware for L4
    system](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.21.5958),
    2000, Jork Löser, Michael Hohmuth

  * [Userdev: A Framework For User Level Device Drivers In
    Linux](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.3.4461),
    2000, Hari Krishna Vemuri

  * [User Mode Drivers](http://www.linuxjournal.com/article/5442), 2002, Bryce
    Nakatani

  * [Towards Untrusted Device
    Drivers](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.13.1725),
    2003, Ben Leslie, Gernot Heiser

  * [Encapsulated User-Level Device Drivers in the Mungi Operating
    System](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.6.1531),
    2004, Ben Leslie Nicholas, Nicholas FitzRoy-Dale, Gernot Heiser

  * [Linux Kernel Infrastructure for User-Level Device
    Drivers](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.10.1408),
    2004, Peter Chubb

      * [Get More Device Drivers out of the
        Kernel!](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.59.6333),
        2004, Peter Chubb

      * <http://gelato.unsw.edu.au/IA64wiki/UserLevelDrivers>

  * [Initial Evaluation of a User-Level Device
    Driver](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.59.4531),
    2004, Kevin Elphinstone, Stefan Götz

  * [User-level Device Drivers: Achieved
    Performance](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.59.6766),
    2005, Ben Leslie, Peter Chubb, Nicholas FitzRoy-Dale, Stefan Götz, Charles
    Gray, Luke Macpherson, Daniel Potts, Yueting Shen, Kevin Elphinstone,
    Gernot Heiser

  * [Virtualising
    PCI](http://www.ice.gelato.org/about/oct06_presentations.php#pres14), 2006,
    Myrto Zehnder, Peter Chubb

  * [Microdrivers: A New Architecture for Device
    Drivers](http://www.cs.rutgers.edu/~vinodg/papers/hotos2007/), 2007, Vinod
    Ganapathy, Arini Balakrishnan, Michael M. Swift, Somesh Jha

      * <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.109.2623>
        [[!tag open_issue_documentation]]

      * <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.146.2170>
        [[!tag open_issue_documentation]]


# External Projects

  * [[/DDE]]

  * <http://ertos.nicta.com.au/research/drivers/uldd/>

  * <http://gelato.unsw.edu.au/IA64wiki/UserLevelDrivers>


## The Anykernel and Rump Kernels

  * [Running applications on the Xen
    Hypervisor](http://blog.netbsd.org/tnf/entry/running_applications_on_the_xen),
    Antti Kantee, 2013-09-17.  [The Anykernel and Rump
    Kernels](http://www.netbsd.org/docs/rump/).


### IRC, freenode, #hurd, 2014-02-13

    <cluck> is anyone working on getting netbsd's rump kernel working under
      hurd? it seems like a neat way to get audio/usb/etc with little extra
      work (it might be a great complement to dde)
    <braunr> noone is but i do agree
    <braunr> although rump wasn't exactly designed to make drivers portable,
      more subsystems and higher level "drivers" like file systems and network
      stacks
    <braunr> but it's certainly possible to use it for drivers to without too
      much work
    <curious_troll> cluck: I am reading about rumpkernels and his thesis.
    <cluck> braunr: afaiu there is (at least partial) work done on having it
      run on linux, xen and genode [unless i misunderstood the fosdem'14 talks
      i've watched so far]
    <cluck> "Generally speaking, any driver-like kernel functionality can be
      offered by a rump server. Examples include file systems, networking
      protocols, the audio subsystem and USB hardware device drivers. A rump
      server is absolutely standalone and running one does not require for
      example the creation and maintenance of a root file system."
    <cluck> from http://www.netbsd.org/docs/rump/sptut.html
    <braunr> cluck: how do they solve resource sharing problems ?
    <cluck> braunr: some sort of lock iiuc, not sure if that's managed by the
      host (haven't looked at the code yet)
    <braunr> cluck: no, i mean things like irq sharing ;p
    <braunr> bus sharing in general
    <braunr> netbsd has a very well defined interface for that, but i'm
      wondering what rump makes of it
    <cluck> braunr: yes, i understood
    <cluck> braunr: just lacking proper terminology to express myself
    <cluck> braunr: at least from the talk i saw what i picked up is it behaves
      like netbsd inside but there's some sort of minimum support required from
      the "host" so the outside can reach down to the hw
    <braunr> cluck: rump is basically glue code
    <cluck> braunr: but as i've said, i haven't looked at the code in detail
      yet
    <cluck> braunr: yes
    <braunr> but host support, at least for the hurd, is a bit more involved
    <braunr> we don't merely want to run standalone netbsd components
    <braunr> we want to make them act as real hurd servers
    <braunr> therefore tricky stuff like signals quickly become more
      complicated
    <braunr> we also don't want it to use its own RPC format, but instead use
      the native one
    <cluck> braunr: antti says required support is minimal
    <braunr> but again, compared to everything else, the porting effort / size
      of reusable code base ratio is probably the lowest
    <braunr> cluck: and i say we don't merely want to run standalone netbsd
      components on top of a system, we want them to be our system
    <cluck> braunr: argh.. i hate being unable to express myself properly
      sometimes :|
    <cluck> ..the entry point?!
    <braunr> ?
    <cluck> dunno what to call them
    <braunr> i understand what you mean
    <braunr> the system specific layer
    <braunr> and *againù i'm telling you our goals are different
    <cluck> yes, anyways.. just a couple of things, the rest is just C
    <braunr> when you have portable code such as found in netbsd, it's not that
      hard to extract it, create some transport between a client and a server,
      and run it
    <braunr> if you want to make that hurdish, there is more than that
    <braunr> 1/ you don't use tcp, you use the native microkernel transport
    <braunr> 2/ you don't use the rump rpc code over tcp, you create native rpc
      code over the microkernel transport (think mig over mach)
    <braunr> 3/ you need to adjust how authentication is performed (use the
      auth server instead of netbsd internal auth mechanisms)
    <braunr> 4/ you need to take care of signals (if the server generates a
      signal, it must correctly reach the client)
    <braunr> and those are what i think about right now, there are certainly
      other details
    <cluck> braunr: yes, some of those might've been solved already, it seems
      the next genode release already has support for rump kernels, i don't
      know how they went about it
    <cluck> braunr: in the talk antii mentions he wanted to quickly implement
      some i/o when playing on linux so he hacked a fs interface 
    <cluck> so the requirements can't be all that big
    <cluck> braunr: in any case i agree with your view, that's why i found rump
      kernels interesting in the first place
    <braunr> i went to the presentation at fosdem last year
    <braunr> and even then considered it the best approach for
      driver/subsystems reuse on top of a microkernel
    <braunr> that's what i intend to use in propel, but we're far from there ;p
    <cluck> braunr: tbh i hadn't paid much attention to rump at first, i had
      read about it before but thought it was more netbsd specific, the genode
      mention piked my interest and so i went back and watched the talk, got
      positively surprised at how far it has come already (in retrospect it
      shouldn't have been so unexpected, netbsd has always been very small,
      "modular", with clean interfaces that make porting easier)
    <braunr> netbsd isn't small at all
    <braunr> not exactly modular, well it is, but less than other systems
    <braunr> but yes, clean interfaces, explicitely because their stated goal
      is portability
    <braunr> other projects such as minix and qnx didn't wait for rump to reuse
      netbsd code
    <cluck> braunr: qnx and minix have had money and free academia labor done
      in their favor before (sadly hurd doesn't have the luck to enjoy those
      much)
    <cluck> :)
    <braunr> sure but that's not the point
    <braunr> resources or not, they chose the netbsd code base for a reason
    <braunr> and that reason is portability
    <cluck> yes
    <cluck> but it's more work their way
    <braunr> more work ?
    <cluck> with rump we'd get all those interfaces for free
    <braunr> i don't know
    <braunr> not for free, certainly not
    <cluck> "free"
    <braunr> but the cost would be close to as low as it could possibly be
      considering what is done
    <cluck> braunr: the small list of dependencies makes me wonder if it's
      possible it'd build under hurd without any mods (yes, i know, very
      unlikely, just dreaming here)
    <braunr> cluck: i'd say it's likely
    <youpi> I quickly tried to build it during the talk
    <youpi> there are PATH_MAX everywhere
    <braunr> ugh
    <youpi> but maybe that can be #defined
    <youpi> since that's most probably for internal use
    <youpi> not interaction with the host