Skip to content
Snippets Groups Projects
Commit 9ef11b71 authored by Moritz Knaut's avatar Moritz Knaut
Browse files

* Added protocol for 21_05

* Changed dir structure
* Added new docs for backside and register functions
parent 9a7c6160
No related branches found
No related tags found
No related merge requests found
Pipeline #
File moved
Possibilites for backside:
- Character devices
- Over ioctl
- Over read/write
- Sysfs
- Big data amount over mmap
### 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.
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)
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment