Something went wrong on our end
Select Git revision
-
Peng Xu authored
This allows system app, regular app as well as test app to access ContextHubManager API. Additional "signature|privilige" permission requirement (LOCATION_HARDWARE) still exist to prevent security issues, misuse and abuse. Change-Id: I47f3d243a3de7f1202c933fc715a935c43cf319b
Peng Xu authoredThis allows system app, regular app as well as test app to access ContextHubManager API. Additional "signature|privilige" permission requirement (LOCATION_HARDWARE) still exist to prevent security issues, misuse and abuse. Change-Id: I47f3d243a3de7f1202c933fc715a935c43cf319b
register_functions 1.91 KiB
### 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.