| | 25 | |
| | 26 | === Device Graph === |
| | 27 | |
| | 28 | ==== Devices and Functions ==== |
| | 29 | |
| | 30 | The traditional view of the device graph, which models the system topology, is a tree which has a single type of node (device node). There are two interested parties to each device node, the bus driver (parent) and the device driver (child). Each views the same node from a different perspective. |
| | 31 | |
| | 32 | From the point of view of the bus driver, the node identifies a device on the bus that the bus driver can provide access to, or, more broadly, a service/function provided by the bus driver. From the point of view of the child/device driver, the same node represents a device that the driver is handling (that usually corresponds to what is considered an ''instance'' of the driver). The device driver accesses the device via the parent (bus) driver and identifies the device using the device node. |
| | 33 | |
| | 34 | In HelenOS DDF this traditional model is slightly modified. We split the single type of node -- having two roles -- into two node types, ''device node'' and ''function node''. Having done that, each driver consumes device nodes and provides function nodes. From the driver perspective, these are represented by distinct C types, ''ddf_dev_t'' and ''ddf_fun_t''. |
| | 35 | |
| | 36 | ==== Inner and Exposed Functions ==== |
| | 37 | |
| | 38 | There is no formal distinction between a bus (nexus) driver and a leaf (device) driver. All drivers consume device nodes and produce function nodes. There are two type of functions (function nodes), ''inner functions'' and ''exposed functions''. Inner functions are functions internal to the device graph and DDF will attempt to attach child devices/drivers under these functions. Exposed functions are meant to be consumed by clients external to the DDF (such as applications or non-DDF servers) and the DDF will expose them as locfs services. |
