Something went wrong on our end
Select Git revision
-
William Roberts authored
A common source of mistakes when authoring sepolicy is properly setting up property sets. This is a 3 part step of: 1. Allowing the unix domain connection to the init/property service 2. Allowing write on the property_socket file 3. Allowing the set on class property_service The macro unix_socket_connect() handled 1 and 2, but could be confusing for first time policy authors. 3 had to be explicitly added. To correct this, we introduce a new macros: set_prop(sourcedomain, targetprop) This macro handles steps 1, 2 and 3. No difference in sediff is expected. Change-Id: I630ba0178439c935d08062892990d43a3cc1239e Signed-off-by:
William Roberts <william.c.roberts@linux.intel.com>
William Roberts authoredA common source of mistakes when authoring sepolicy is properly setting up property sets. This is a 3 part step of: 1. Allowing the unix domain connection to the init/property service 2. Allowing write on the property_socket file 3. Allowing the set on class property_service The macro unix_socket_connect() handled 1 and 2, but could be confusing for first time policy authors. 3 had to be explicitly added. To correct this, we introduce a new macros: set_prop(sourcedomain, targetprop) This macro handles steps 1, 2 and 3. No difference in sediff is expected. Change-Id: I630ba0178439c935d08062892990d43a3cc1239e Signed-off-by:
William Roberts <william.c.roberts@linux.intel.com>
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.