1 = System Architecture = 2 3 A significant motivation for providing server programs is to isolate 4 device-specific operations within separate components, thus preventing each 5 component from having too broad access to low-level system functionality. The 6 combination of components is then encouraged to achieve configuration 7 objectives. 8 9 For example, two computing systems that employ the same LCD controller might 10 each employ different screen types and have different ways of controlling 11 display behaviour. By defining explicit mechanisms for combining access to 12 these different aspects of the hardware, common elements (such as the LCD 13 controller) may be encapsulated by a device server that can be reused, with 14 differing elements (such as the screen type) being described by separate 15 resources or components that can be introduced as required. 16 17 Here is how the Ben NanoNote's framebuffer is supported by components: 18 19 ######## A graph showing the relationship between components. 20 21 {{{#!graphviz 22 #format svg 23 #transform notugly 24 digraph nanonote_framebuffer { 25 node [shape=rectangle,fontsize="13.0",fontname="sans-serif"]; 26 27 fb_drv [label="fb-drv"]; 28 dev_cpm_jz4740 [label="dev_cpm_jz4740\nClock configuration"]; 29 dev_display_qi_lb60 [label="dev_display_qi_lb60\nDisplay control"]; 30 dev_backlight_spi_ili8960 [label="dev_backlight_spi_ili8960\nBacklight control"]; 31 dev_spi_jz4740 [label="dev_spi_jz4740\nBacklight communication"]; 32 33 fb_drv -> dev_cpm_jz4740; 34 fb_drv -> dev_display_qi_lb60 -> dev_backlight_spi_ili8960 -> dev_spi_jz4740; 35 } 36 }}} 37 38 ######## 39 40 And here is how the Letux 400's framebuffer is supported: 41 42 ######## A graph showing the relationship between components. 43 44 {{{#!graphviz 45 #format svg 46 #transform notugly 47 digraph letux400_framebuffer { 48 node [shape=rectangle,fontsize="13.0",fontname="sans-serif"]; 49 50 fb_drv [label="fb-drv"]; 51 dev_cpm_jz4730 [label="dev_cpm_jz4730\nClock configuration"]; 52 dev_display_letux400 [label="dev_display_letux400\nDisplay control"]; 53 dev_backlight_pwm [label="dev_backlight_pwm\nBacklight control"]; 54 dev_pwm_jz4730 [label="dev_pwm_jz4730\nBacklight communication"]; 55 56 fb_drv -> dev_cpm_jz4730; 57 fb_drv -> dev_display_letux400 -> dev_backlight_pwm -> dev_pwm_jz4730; 58 } 59 }}} 60 61 ######## 62 63 Note that fb-drv links to the same generic JZ4740 LCD controller library in 64 both cases 65 66 Here, the CPM device provides access to the clock and power management 67 functionality, the display device provides access to the backlight and is 68 responsible for configuring pins for the display. Device servers are connected 69 using capabilities (object references). 70 71 Meanwhile, panel information is provided via a dynamically-loaded library: 72 73 ######## A graph showing the acquisition of panel information. 74 75 {{{#!graphviz 76 #format svg 77 #transform notugly 78 digraph panel_information { 79 node [shape=rectangle,fontsize="13.0",fontname="sans-serif"]; 80 81 subgraph { 82 rank=min; 83 fb_drv [label="fb-drv"]; 84 } 85 86 paneldata [label="mips-jz4740-panel.txt\nLibrary details"]; 87 library [label="...\nLibrary with panel data"]; 88 89 paneldata -> fb_drv -> library; 90 } 91 }}} 92 93 ######## 94 95 This method of obtaining a configured library name in order to load it 96 dynamically is effectively equivalent to having a symbolic link identifying 97 the library referencing the desired, specific library to be used. Since the 98 "rom" virtual filesystem does not appear to support symbolic links, this 99 method is used instead. 100 101 By providing well-defined interfacing mechanisms, the behaviour of driver code 102 can be parameterised using external components, and a proliferation of 103 specially-constructed device drivers is hopefully avoided.