Udisks is a means of enumerating disk and storage devices on Linux platforms and performing various operations on them. This post describes the technology behind udisks, the history of udisks, how to monitor udisks events and some simple operations you can do using udisks.
|
|
|||||||||||||||||||||||
    |
Earlier this year I wrote a number of posts about monitoring and interacting with D-Bus using shell scripts. In this post I look at using Ruby to monitor and interact with D-Bus enabled applications. Monitoring D-Bus messages is important for both activation and debugging purposes. In this post I examine how to monitor and act on such messages using command line tools. Tomboy is an open source GNOME desktop note-taking application which is written in C# and utilizing the Mono runtime, Gtk# and the GtkSpell spell-checker. The actual release of Tomboy which comes with Fedora 10 is version 0.12.0. This includes a comprehensive D-Bus interface which makes it possible to create, modify and display Tomcat notes from your shell scripts. This post provides an overview of the available D-Bus methods and includes a number of examples for you to experiment with. See my previous post on D-Bus scripting if you are unfamilar with the basic concepts of D-Bus scripting. First we will list the available objects using qdbus. $ qdbus org.gnome.Tomboy / /org /org/gnome /org/gnome/Tomboy /org/gnome/Tomboy/RemoteControl Next, we list all the available signals and methods for RemoteControl. $ qdbus org.gnome.Tomboy /org/gnome/Tomboy/RemoteControl method QString org.freedesktop.DBus.Introspectable.Introspect() method bool org.gnome.Tomboy.RemoteControl.AddTagToNote(QString uri, QString tag_name) method QString org.gnome.Tomboy.RemoteControl.CreateNamedNote(QString linked_title) method QString org.gnome.Tomboy.RemoteControl.CreateNote() method bool org.gnome.Tomboy.RemoteControl.DeleteNote(QString uri) method bool org.gnome.Tomboy.RemoteControl.DisplayNote(QString uri) method bool org.gnome.Tomboy.RemoteControl.DisplayNoteWithSearch(QString uri, QString search) method void org.gnome.Tomboy.RemoteControl.DisplaySearch() method void org.gnome.Tomboy.RemoteControl.DisplaySearchWithText(QString search_text) method QString org.gnome.Tomboy.RemoteControl.FindNote(QString linked_title) method QString org.gnome.Tomboy.RemoteControl.FindStartHereNote() method QStringList org.gnome.Tomboy.RemoteControl.GetAllNotesWithTag(QString tag_name) method qlonglong org.gnome.Tomboy.RemoteControl.GetNoteChangeDate(QString uri) method QString org.gnome.Tomboy.RemoteControl.GetNoteCompleteXml(QString uri) method QString org.gnome.Tomboy.RemoteControl.GetNoteContents(QString uri) method QString org.gnome.Tomboy.RemoteControl.GetNoteContentsXml(QString uri) method qlonglong org.gnome.Tomboy.RemoteControl.GetNoteCreateDate(QString uri) method QString org.gnome.Tomboy.RemoteControl.GetNoteTitle(QString uri) method QStringList org.gnome.Tomboy.RemoteControl.GetTagsForNote(QString uri) method bool org.gnome.Tomboy.RemoteControl.HideNote(QString uri) method QStringList org.gnome.Tomboy.RemoteControl.ListAllNotes() signal void org.gnome.Tomboy.RemoteControl.NoteAdded(QString uri) signal void org.gnome.Tomboy.RemoteControl.NoteDeleted(QString uri, QString title) method bool org.gnome.Tomboy.RemoteControl.NoteExists(QString uri) signal void org.gnome.Tomboy.RemoteControl.NoteSaved(QString uri) method bool org.gnome.Tomboy.RemoteControl.RemoveTagFromNote(QString uri, QString tag_name) method QStringList org.gnome.Tomboy.RemoteControl.SearchNotes(QString query, bool case_sensitive) method bool org.gnome.Tomboy.RemoteControl.SetNoteCompleteXml(QString uri, QString xml_contents) method bool org.gnome.Tomboy.RemoteControl.SetNoteContents(QString uri, QString text_contents) method bool org.gnome.Tomboy.RemoteControl.SetNoteContentsXml(QString uri, QString xml_contents) method QString org.gnome.Tomboy.RemoteControl.Version() As a simple example of how to use a published method, we invoke the Version method to return the version of Tomboy that we are using. $ qdbus org.gnome.Tomboy /org/gnome/Tomboy/RemoteControl org.gnome.Tomboy.RemoteControl.Version 0.12.0 We can use dbus-send instead of qdbus as shown below but, as you can, see qdbus syntax is more compact. Also note that we have to use the session bus. $ dbus-send –type=method_call –session –print-reply \ –dest=’org.gnome.Tomboy’ /org/gnome/Tomboy/RemoteControl \ org.gnome.Tomboy.RemoteControl.Version 0.12.0 In the following example, we create the equivalant of “Hello World” using a note, display it for 5 seconds and then delete the note. #!/bin/bash DPATH=”/org/gnome/Tomboy/RemoteControl” INTERFACE=”org.gnome.Tomboy.RemoteControl” TMP=`qdbus org.gnome.Tomboy ${DPATH} ${INTERFACE}.CreateNamedNote “My Note” 2>/dev/null` RESULT=$? if [[ $RESULT != 0 ]] then exit 1 fi # figure out note uri string which is of the form # note://0xaf3356abcdefg OID=${TMP#note:} # set the contents of D-Bus (Desktop Bus) is a low-latency, low-overhead, easy-to-use message bus technology which supports application launch and linking. It is primarly used on GNU/Linux desktops but has been ported to other platforms including Microsoft Windows and Apple Mac OS X.  This post provides a quick overview of D-Bus concepts, some history, and some examples of how to use D-Bus in your shell scripts. Originally both the KDE and GNOME desktop projects used CORBA for inter-application communication. Over time however, for various reasons, KDE migrated from CORBA to Desktop Comunications Protocol (DCOP) and GNOME migrated to Bonono. This lead to the situation where GNU/Linux desktop distributions had to support two different inter-application lauch and linking models and many standard desktop applications could not communicate seamlessly with each other. To ameliorate this unsatisfactory situation, D-Bus (the name was suggested by Harri Porten) was conceived and developed by Red Hat as part of the freedesktop.org project. The design of D-Bus was heavily influenced by DCOP. From the start, it was designed to be a replacement for the two competing technologies. The initial source code module was created by Havoc Pennington in late 2002. Development was quite slow with many changes to the wire protocol. However by 2006 the specification was relatively stable. First GNOME and then KDE made the decision to transition to D-Bus in order to support a single unified applcation linking and lauching technology on GNU/linux desktops. In many ways D-Bus is similar to Sun Microsystems ToolTalk which is the undelying technology in Common Desktop Environment, and Microsoft’s Object Linking and Embedding (OLE) technology. The basic D-Bus protocol is a low latancy peer-to-peer or client-server binary protocol. It is not intended for inter-machine use but rather for intra-machine use. It works in terms of messages rather than byte streams. A message bus is used when many-to-many communication is desired. Normally applications communicate via such a message bus but direct application-to-application communication is also possible. When communicating on a message bus, applications can query which other applications and services are available, as well as activate one on demand. A daemon, or service, must be launched before any applications can connect to a message bus. This daemon is responsible for keeping track of the applications that are connected and for properly routing messages from source to destination. The D-Bus specification defines two well-known buses called the system bus and the session bus. |
||||||||||||||||||||||
|
Copyright © 2005-2012 Finnbarr P. Murphy. All Rights Reserved. |
|||||||||||||||||||||||