diff --git a/docs/intervention_points b/docs/14_5_2016/intervention_points
similarity index 100%
rename from docs/intervention_points
rename to docs/14_5_2016/intervention_points
diff --git a/docs/21_05_2016/backside b/docs/21_05_2016/backside
new file mode 100644
index 0000000000000000000000000000000000000000..86e1cdfffbeb8144eaeb8a0ff4cd887f816beee5
--- /dev/null
+++ b/docs/21_05_2016/backside
@@ -0,0 +1,6 @@
+Possibilites for backside:
+- Character devices
+	- Over ioctl
+	- Over read/write
+- Sysfs
+- Big data amount over mmap
diff --git a/docs/21_05_2016/register_functions b/docs/21_05_2016/register_functions
new file mode 100644
index 0000000000000000000000000000000000000000..c5d7295ee6fde8b609efe6eb20a32bfdbe9eb740
--- /dev/null
+++ b/docs/21_05_2016/register_functions
@@ -0,0 +1,60 @@
+### Important:
+USBIP does not register directly via usb_... instead it first
+registers a platform driver and matching platform device. In the platform
+driver it then registers itself as usb controller.
+
+=> All other modules with non-real-bus components seem to do the same thing.
+So we should probably do the same. This approach is also better because
+the system then knows that there is a driver and we can monitor it better.
+
+
+### BLOCK/CHARACTER 
+Trivial over register_chrdev, register_blkdev
+
+### USB:
+HCD means Host Controller Device
+See: usbip
+usb_create_hcd(...)
+usb_add_hcd(...)
+usb_put_hcd(...)
+
+
+### ATA:
+ata_host_register(...)
+/drivers/ata/pata_cs5520.c
+
+ata_host_alloc_pinfo(...)
+ata_port_pbar_desc(...)
+ata_host_activate(...)
+/drivers/ata/sata_sx4.c
+
+There are a lot of options. The ata operations are inherited between the drivers. Closer look needed here. struct ata_port_operations are the operations supported by a ata device.
+These have to be overriden because defaults (in libata-sff.c) use direct port access.
+
+
+### NETWORK DEVICE:
+register_netdev(...) 
+See: http://linuxgazette.net/156/jangir.html
+
+
+### TTY DEVICE:
+struct tty_operations
+struct tty_port_operations
+
+alloc_tty_driver(...)
+tty_set_operations(...)
+tty_register_driver(...)
+See: /drivers/tty/isicom.c
+
+Uart etc is below this interface, we could also just add a serial device (uart).
+
+
+### GRAPHIC CARD:
+Is possible via struct drm_driver
+
+See: /drivers/gpu/drm/bochs/[bocks_drv.c]
+
+### GENERAL
+The general approach is to search for a layer where we want to inject out device. Then we implement a driver which does everything under this layer. All the drivers which are over our layer are used and can be debugged. All the drivers under our layer are not used and can not be debugged. The device concept in the linux kernel is orthogonal to this layers, because all the layer drivers are in a shared context as "drivers".
+
+TODO: Draw some kind of map which shows this layers.
diff --git a/protocols/PROTOCOL_21_05_2016 b/protocols/PROTOCOL_21_05_2016
new file mode 100644
index 0000000000000000000000000000000000000000..b94164be8234e8c71a25c1d65d8a97abfb7d8f0e
--- /dev/null
+++ b/protocols/PROTOCOL_21_05_2016
@@ -0,0 +1,10 @@
+TODOs for next week:
+- Create stub module which registers as usb_controller on "front side"
+- Find the register_controller equivalents for other controllers (scsi | ata)
+- Gather some ideas for backside (character-device(read?, ioctl?), block-device, sysfs, proc)
+
+Devices should not be registered at low-level buses (e.g. PCI). Instade they should
+register at the high-level interfaces (e.g. register_host_controller). 
+
+Backside should be able to serve multiple devices. 
+(e.g. create 16 ports on the backside, write determines which device to register)