Concepts with Symbian OS (779878), страница 50
Текст из файла (страница 50)
Hardware is becoming increasingly standardized and sometimes one devicedriver can manage several pieces of hardware because they all abideby the same standard. For example, many serial devices – modemsor IR ports – can be controlled by a single device driver. In addition, protocol implementations are increasingly assuming device-driverstandards. Standards such as Bluetooth or wireless Ethernet, for instance,are becoming widely supported and therefore must be incorporated inthe device-driver layer.The next layer up is the protocol-implementation layer.
This layercontains implementations of the protocols supported by Symbian OS.These implementations assume a device-driver interface with the layerbeneath and supply a single, unified interface to the application layerabove. This is the layer that implements the Bluetooth and TCP/IP protocolsuites, for example, along with other protocols.Finally, the application layer contains the application that must utilizethe communications infrastructure. The application does not know muchabout how communications are implemented – however, it does do thework necessary to inform the operating system of which devices it use.Once the drivers are in place, the application does not access themdirectly, but depends on the protocol-implementation-layer APIs to drivethe real devices.COMMUNICATIONS ON SYMBIAN OS239A Closer Look at the InfrastructureNow let’s take a closer look at the layers in Symbian OS communicationsinfrastructure.
Figure 11.6 contains a new diagram based on the genericmodel in Figure 11.5. The blocks from Figure 11.5 have been subdividedinto operational units that depict those used by Symbian OS.The physical deviceFirst, notice that the device has not been changed. As we stated before,Symbian OS has no control over hardware. Therefore, it accommodateshardware through this layered API design, but does not specify howthe hardware itself is designed and constructed. This is an advantageto Symbian OS and its developers. By viewing hardware as an abstractunit and designing communications around this abstraction, the designersApplicationUser-side codeCSY communication module (application)Protocol ImplementationMTM modulePRT protocol moduleTSY communication moduleCSY communication moduleSOFTWAREDevice DriverLogical device driverPhysical device driverPhysical deviceHARDWAREFigure 11.6 Detailed look at the Symbian OS communications infrastructure240MODELING COMMUNICATIONShave ensured that Symbian OS handles the wide variety of devices thatare available now and that it can accommodate the hardware of thefuture.The device-driver layerThe device-driver layer of Figure 11.5 has been divided into two layersin Figure 11.6.
The physical device-driver (PDD) layer interfaces directlywith the physical device, through a specific hardware port. The logicaldevice-driver (LDD) layer interfaces with the protocol-implementationlayer and implements Symbian OS policies as they relate to the device.These policies include input and output buffering, interrupt mechanismsand flow control. The division of these layers represents a division inimplementation, where the PDD implementers can focus on an efficientand correct hardware interface and the LDD implementers can work toperfect the interface with the upper layers to maximize performance.User code interfaces with the LDD through the RBusLogicalChannel class.
This is a simple interface that all user code interactions gothrough. Note that this class is used no matter if the device is the display,a Bluetooth transmitter, or an infrared port. This provides a layer ofabstraction that results in a consistent interface to the physical device.The PDD provides the connection to the physical device. It interfaceswith the LDD using an interface designed by the LDD.As an example of this division of responsibilities, consider the serialinterface. There are several serial-device types that can be connected toa Symbian OS device. The IR port and the RS232 port are both serialdevices and can use the same generic serial LDD, called ECOMM.LDD.These ports are serial ports and use the same policies with respect toissues such as flow control.
However, their PDD modules are different:one services the RS232 port and one services the IR port. Other examplesinclude the Ethernet driver (ENET.LDD and ETHERNET.PDD) and thesound driver (ESOUND.LDD and ESDRV.PDD).Chapter 9 contains more information about device drivers and kernelextensions. There are many more details about these items that are notrelevant here.The protocol-implementation layerSeveral sublayers have been added to the protocol-implementation layer.Four types of module are used for protocol implementation.COMMUNICATIONS ON SYMBIAN OS241• CSY modules : the lowest level in the protocol implementation layeris the communications server.
A CSY module communicates directlywith the hardware through the PDD portion of the device driver,implementing the various low-level aspects of protocols. For instance,a protocol may require raw data transfer to the hardware device orit may specify 7-bit or 8-bit buffer transfer. These ‘modes’ would behandled by the CSY module. Note that CSY modules may use otherCSY modules. For example, the IrDA CSY module that implementsthe IrCOMM interface to the IR PDD also uses the serial device driver,ECUART CSY module.• TSY modules : telephony comprises a large part of the communications infrastructure and special modules are used to implement it.The telephony server (TSY) modules implement the telephony functionality. Basic TSYs may support standard telephony functions, e.g.,making and terminating calls, on a wide range of hardware.
Moreadvanced TSYs may support advanced phone hardware, e.g., thosesupporting GSM functionality.• PRT modules : the central modules used for protocol implementation,protocol (PRT) modules, are used by servers to implement protocols. Aserver creates an instance of a PRT module when it attempts to use theprotocol. The TCP/IP suite of protocols, for instance, is implementedby the TCPIP.PRT module. Bluetooth protocols are implemented bythe BT.PRT module.• MTMs : as Symbian OS has been designed specifically for messaging,its architects built a mechanism to handle messages of all types. Thesemessage handlers are called message type modules (MTMs). Messagehandling has many different aspects and MTMs must implementeach of these aspects.
User-interface MTMs must implement thevarious ways users view and manipulate messages, from how auser reads a message to how a user is notified of the progress ofsending a message. Client-side MTMs handle addressing, creating andresponding to messages. Server-side MTMs must implement serveroriented manipulation of messages, including folder manipulationand message-specific manipulation.These modules build on each other in various ways, depending on thetype of communications that is being used. Implementations of protocolsusing Bluetooth, for example, use only PRT modules on top of devicedrivers. Certain IrDA protocols do this as well.
TCP/IP implementations242MODELING COMMUNICATIONSthat use PPP use PRT modules, a TSY module and a CSY module. TCP/IPimplementations without PPP typically do not use either a TSY module ora CSY module but link a PRT module directly to a network device driver.The WAP protocol stack uses a WAP PRT on top of an SMS PRT, whichin turn is built on a GSM TSY and some kind of CSY (ECUART, IrCOMM,or RFCOMM).Infrastructure modularityWe should take a moment to appreciate the modularity of the stackbased model used by the communications infrastructure design. The‘mix and match’ quality of the layered design should be evident fromthe examples just given. Consider the TCP/IP stack implementation.
APPP connection can go directly to a CSY module or choose a GSM orregular modem TSY implementation, which in turn goes through a CSYmodule. When the future brings a new telephony technology, the existingstructure works and we only need to add a TSY module for the newtelephony implementation. In addition, fine-tuning the TCP/IP protocolstack does not require altering any of the modules it depends on; wesimply tune up the TCP/IP PRT module and leave the rest alone.
Thisextensive modularity means new code plugs into the infrastructure easily,old code is easily discarded and existing code can be modified withoutshaking the whole system or requiring any extensive reinstallations.Finally, Figure 11.6 has added sublayers to the application layer. Thereare CSY modules that applications use to interface with protocol modulesin the protocol implementations. While we can consider these as parts ofprotocol implementations, it is a bit cleaner to think of them as assistingapplications.
An example here might be an application that uses IR tosend SMS messages through a mobile phone. This application would usean IRCOMM CSY module on the application side that uses an SMS implementation wrapped in a protocol-implementation layer. Again, the modularity of this entire process is a big advantage for applications that needto focus on what they do best and not on the communications process.11.3Communications on Other Operating SystemsSymbian OS is a great example of the way that most other operatingsystems model communications. Figure 11.6 is a good way to depictthe application of I/O concepts to communications in other operatingsystems.COMMUNICATIONS ON OTHER OPERATING SYSTEMS243Device drivers are the way operating systems tie physical communications-hardware devices into the system.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
