Maemo Linux Mobile Platform Series Analysis: 6 Maemo Platform Development D-bus __linux

    in the Maemo platform, D-bus is a very important middleware (middleware) solution, primarily for communication between processes. There are already a lot of services using D-bus, and then there are different ways to implement them. D-bus is run through the Maemo platform, inseparable from the D-bus.  

  This part of the content: introduce the D-bus d-bus architecture D-bus address and name in the Maemo D-bus function directly with D-bus the underlying library Libdbus programming   D-bus Introduction D-bus (where D was originally representing desktop "D Esktop "means: A communication bus for desktop operating systems. It is now being introduced into embedded systems, but the name remains the original term. D-bus is relatively new interprocess communication (IPC) mechanism, in the desktop operating system, playing a unified middle of a role. There are a lot of projects used D-bus, such as: GNOME, Hildon, etc. compared to other IPC, D-bus lost some unnecessary, complex things, it is because of this reason, d-bus faster and simpler. D-bus does not compete directly with low-level IPC, such as sockets, shared memory or message queues. These low-level points of IPC have their own characteristics, and D-bus does not conflict. In fact, the main purpose of D-bus is to provide some of the more high-level features: structured namespaces are independent of the schema's data format support for most common data elements in a message The universal remote invocation interface with exception handling supports broadcast type communication between the system and the user with a clear distinction, This is important for handling multi-user systems, not limited to any particular programming language, it also provides a method of language binding that can be used in conjunction with some common high-level language bindings, such as C, C + +, Python, and other D-bus design benefits from the long experience of other IPC in desktop systems, and it is with these rich experiences , so that the design of D-bus can be optimized. At the same time D-bus will not be affected by slow functional improvements (creeping featurism). All of the above, the core of the problem reflected: the purpose of the D-bus is to provide a very easy to use IPC for desktop software, of course, now also for the embedded system services. In Maemo, D-bus plays a very, very large role. Because D-bus is used when using the services provided by the Maemo platform. At the same time, it is the easiest way to provide some services on the basis of D-bus, which can also achieve the purpose of module reuse. In short, there are many benefits. D-bus architecture and some terms: in D-bus, "bus" is the core concept, it is a channel: different programs can do some operations through this channel, such as method calls, send signals and listen to specific signals. There are two kinds of notSame channel: Session channel, System Bus (channel): Session channel handles communication between different programs that are connected to the same desktop task, i.e. the system channel is initiated and run by the same user to provide communication between different programs in different session environments. The most common aspect of this channel is sending system messages, such as inserting a new storage device, having a new network connection, and so on. Typically, only one system channel exists, but there can be different session channels (one for each desktop session). In Internet Tablet products, all applications run with a single user ID, so there is only one session channel, which is clearly different from the Linux desktop system, please note. What is the existing form of the channel in the system? is in the form of bus daemon, the bus daemon is a special process: This process can pass messages from one process to another process. Of course, if a lot of applications are linked to this channel, the daemon process forwards the messages to all of these linked programs. At the bottom, D-bus only supports point-to-point communications, and generally uses local sockets (Af_unix) to communicate between applications and bus daemon. D-bus Point-to-Point is abstracted by bus daemon, the bus daemon to complete addressing and sending messages, so each application does not have to care about which process to send the message to. (Note: This addressing is implemented through the service name, which will be mentioned later) the D-bus sent message is usually comprised of the following steps (normally): Creating and sending messages to the background bus daemon process, which will have two context switching background bus The daemon process processes the message and forwards it to the target process, which also causes the target program of the context to receive the message and then respond differently depending on the type of message: either give a confirmation, answer, or ignore it. Last case for messages of type "notification", the first two will cause further context switches. For the most part, if you're going to transfer a lot of data between different processes, D-bus may not be the most efficient way to use shared memory, but the management of shared memory is also quite complex. D-bus address and name in order to send the message to the receiver correctly, the IPC mechanism needs to have some or some addressing capability. The addressing scheme designed by D-bus is very flexible and efficient. Each channel (bus) has its own private name space, which distinguishes it from other channels. In order to send a message, you need toTo know the destination address of the message, in D-bus, this address is a hierarchical address of the following elements: 1 which channel to send this message to. A channel for a program, generally open only once, then the program will use the open channel of a link (tributary), the message sent and received. In this way, the destination channel will be open and transparent, that is to say, everyone knows that there is no need for each message to specify the purpose alone. 2 The receiver also needs to provide a "well known" name, similar to a term in the Internet: DNS (domain name resolution), where people usually use a friendly web site to surf the internet and then convert to a specific IP address via this DNS. D-bus's designers have introduced this idea, which is "well known" and "unique". So, how does this name get up? The name consists of a-Z character (uppercase or lowercase), ".", "underline" _. And there are at least two points in the name. Do not want DNS, the point here is actually no special meaning, just to show that the name is no level and level. To reduce the repetition and conflict of names in the D-bus namespace, we recommend that you organize the D-bus name: The name reverse order, a bit like the Java package name form, look at the example below. Examples: Org.maemo.Alert and org.freedesktop.Notifications. 3 Each service can contain a number of different objects, each offering a different service. To differentiate between these objects, use the object path. The object path is much like a file path. With a backslash/split in the D-bus, it stands to reason that a remote method is invoked to specify its full path, and since we already know the path to the object that provides the method, we can take a lazy approach by simply passing in the method name and then putting the method name back together in the object Path, this can also form a complete full path. Not recommended: (/org/maemo/addressbook/contacts/shortname). It is recommended: ShortName (a string in a UTF-8 encoded format). If the name of a service is: Org.maemo.alert, we can simply change the point to a backslash:/org/maemo/alert, which forms an object path. Like the name, object path has no hierarchical relationship. Even if we use the path separator, it looks like there is a hierarchical relationship, actually not. 4 in order to support object-oriented, in D-bus, the object is the unit that provides the service. These services are implemented through the object's interface (Interface). Interfaces have legal (for example,Defined, implemented) method calls, parameters, and signals. With these features, multiple objects can be reused in order for similar services to be implemented. Or more generally: a single object implements several different services. For example, an interface: Org.freedesktop.DBus.Introspectable defines an interface that supports D-bus introspection functions. For what is introspection, the following is described in detail. If you want to use the D-bus glib encapsulated interface to generate your own D-bus code, the object you define will automatically support the introspection interface. Interface Name: The same rule as the service name. In this way, you may misunderstand at the beginning, but you will get used to it for a long time. In order to simplify the service, commonly known names are used as interface names. 5 The last part of the message address is member. This member is also called method name when processing a remote call; When processing a signal, member is signal name. The member names has characters, numbers, and underscores, such as: Retrievequote. If you want to have a more in-depth understanding of D-bus, to its official website: Introduction to D-bus page. The above is the D-bus address of the most important part of the explanation, you will often face in the future. Here's an example:#defineSysnote_name "org.freedesktop.Notifications"//Service Name#defineSysnote_opath "/org/freedesktop/notifications"//object path name#defineSysnote_iface the name of the "Org.freedesktop.Notifications"//Object interface#defineSysnote_note "Systemnotedialog"//interface method name if you use Libosso (encapsulating a lot of d-bus mechanism) Remote Call function, there will be many opportunities to deal with d-bus of various names, do not worry, hehe. Role in D-bus in Maemo: In Maemo, D-bus was chosen as the de facto IPC mechanism, mainly to pass messages between different software programs. The main reason for choosing D-bus instead of other IPC is that a lot of software uses D-bus in the GNOME environment. It's always good to use something common. However, it is also a pity that the SDK itself does not use much of the software project with D-bus, but we are prepared to use a component in the application framework to demonstrate D-bus usage. We are interested in using the Notification framework component to display a notification dialog box, because this is a simpler example and can be used to clarify the basic usage of d-bus. This dialog box is a modal dialog box, learning VC + + users should be clear what is the Mode/modeless dialog box, here is not much to say. There is a background program: Notification server has been running, it listens to org.freedesktop.Notifications. Its corresponding object path is:/org/freedesktop/notifications; its interface is: Org.freedesktop.Notifications; The interface provides a function: Systemnotedialog, This function displays a modal dialog box. D-bus provides tools to experience method invocation and signal invocation, this tool is: Dbus-send. Below, we try to use a few statements to display a dialog box: [sbox-chinook_x86: ~] >run-standalone.sh dbus-send--print-reply/--type=method_call--dest=org.freedesktop.notifications//org/freedesktop/notifications org.freedesktop.NotificationsError Org.freedesktop.DBus.Error.UnknownMethod:Method "notifications" with signature "" On Interface "Org.freedesktop" doesn ' t exist [the correct method name is not provided here when the Dbus-send command is run] (Dbus-send would considerNotifications is method name, and actually didn't have that name, so it would be an error.Dbus-send Parameters:--session: (default) to which channel to send the message: Session channel or System channel (another option:--system)--print-reply: Tell Dbus-send to wait for a response and print out the result Type=method_call: Indicates a method call, rather than sending a signal (default)--dest=org.freedesktop.notifications: The name of the service, which is considered to provide some function for invocation/org/ Freedesktop/notifications: The object path of the target process org.freedesktop.Notifications: (This is intentionally wrong, there is actually no such method), the method defined in the interface is to use Dbus-send, Pay special attention to a place: interface and method names to be connected together, there should be no spaces in the middle. Make some changes to the above example and try again: [sbox-chinook_x86: ~] >run-standalone.sh dbus-send--print-reply/--type=method_call--dest=org.freedesktop.notifications//org/freedesktop/notifications Org.freedesktop.Notifications.SystemNoteDialogError Org.freedesktop.DBus.Error.UnknownMethod:Method "Systemnotedialog" with Signature "' on Interface" Org.freedesktop.Notifications "doesn ' t exist [interface and method are connected to a piece, but why is it still wrong?" The reason is that you did not give the method: Systemnotedialog pass the parameter, just like we do function calls, the prototype has parameters, but you call without reference, certainly not. The function Systemnotedialog has three parameters: string: The information to display UInt32: Represents a different style of dialog, 0~4 represents a different icon, and 5 is a dialog box with a progress bar. String: Press the OK button for the prompt. parameter to: Type: value