MOBLIN ZONEMOBLIN ZONE


Heute auf Moblin Zone

Abonnieren Sie
TOP STORIES

 Write once, run anywhere – no, this isn’t an article about Java. Our topic is the Moblin Compliance Project, which seeks to define a standard set of libraries for Moblin v2. To be compliant, OSVs (operating system vendors) must include all of those libraries and their interfaces – in the correct versions – in their distributions and on their devices.


Similarly, developers targeting Moblin-based devices must ensure that their applications call only those standard libraries – and their interfaces – in their applications. (If an application requires additional libraries and interfaces, it’s the application developer’s responsibility to ensure that those extra libraries and interfaces are installed on the target device, and are installed in such a way as to not cause difficulties for other applications that might use other versions of those libraries.)

Part 1 of this article introduced the Compliance Project, and described its goals, objects and limitations. The most recent version of the compliance specification, released July 14th, is v0.6.2. We’ll continue our discussion of the Compliance Project by looking at the test automation tools and the process of using those tools to ensure compliance. We’ll conclude by discussing the future direction of the Compliance Project.

Test Tools for Compliance

The foundation of the Compliance Project is an enumerated list of libraries and interfaces which are part of the Moblin v2 core framework. The Moblin V2 Compliance Library Interfaces document contains 1308 pages detailing libraries and their interfaces.

To ensure compliance, and therefore application compatibility, both OSVs and ISVs must test against that standard list. The OSV tests make sure that all of those libraries and interfaces are installed, are of the correct version, and that the libraries are in the right place. The ISV tests make sure that the application only calls those libraries, and flags libraries that an application uses, but which aren’t included in the standard base platform. As mentioned above, if additional specialty libraries are required, it’s then the ISV’s responsibility to install them in a way that doesn’t interfere with the Moblin system itself or with any other applications. (This could be an issue, for example, if a Linux application being ported to Moblin requires a newer or older version of a library that’s included in the Moblin standard platform.)

The Moblin tools are based on those created for the Linux Standard Base.

OSV Tools

There are a lot of libraries in the standard platform, explains Bob Spencer, Intel’s senior engineer in charge of the Compliance Project team, because the Moblin team wanted to create a rich environment for application developers. “We’re trying to make it as easy as possible for ISVs, even if OSVs have to jump through a few more hurdles. We're making the compliance libraries quite broad – there's a lot of libraries for a full set of features, not just the ‘Top 10.’ ” He’s not kidding – there are 1,308 pages of interfaces! For a brief list of libraries and versions required for Moblin v2, check this list.

OSVs should download the OSV Test Kit from the Compliance Project site. It contains two specific tools:
    OSV-library check: It has the extended Linux Standard Base tools that evaluate existence of correct libraries, versions and function signatures. OSV-feature check: It checks for browser features, media features, boot time, suspend-to-RAM time, battery usage, and other quality metrics.


These tools are based on the LSB Distribution Testkit Manager II, so you should refer to the DTK documentation for more details.

ISV Tools

ISVs can download the ISV Application Checker kit. It includes the Moblin App Checker (moblinappchk), which runs against the application binaries, and reports on library usage, correct appearance on the Moblin desktop, and clean package install/uninstall.

According to the Linux Foundation, which hosts the Moblin App Checker, the tool is very similar to the Linux App Checker:

  1. Currently, Moblin AppChecker includes the following of the Linux AppChecker features: Static analysis of applications using underlying command line moblinappchk. The AppChecker allows visually customizing all the options that the tests provide. That is:
    • Moblin version to test against (only 2.0 is supported currently).
    • Additional shared libraries that the application depends on. moblinappchk in this case will check only external functions that cannot be resolved by any of the application's components. Visual interface for specifying the target application as a set of executable files, libraries or whole directories (similar to the usual "Browse..." dialog). Also TAR.GZ, TAR.BZ2, RPM, DEB packages as well as installed RPM or DEB packages can be selected.
  2. High level command line interface (useful e.g. for automated nightly test runs).
  3. Test execution and generating a human-readable report in HTML format. The report contains the list of problems encountered during testing.
  4. Results history management:
    • viewing the list of all test runs on this system;
    • viewing the particular reports of any previous test run;
    • removing old reports that are no longer needed. 
  5. Saving/Loading the configured options in user profiles for quick test runs in the future.

For more about how to use the tool, read the Linux App Checker Getting Started page, since there isn’t one for the Moblin App Checker yet.

Using the Tools

Once you have the tools, says Spencer, the process is straight-forward. OSVs should just run the tools against their Moblin distributions, and add or correct missing libraries.

For ISVs, the process varies, depending on whether you’re writing a new application, or if you’re porting an existing one.

If you are porting an existing Linux application, run the Moblin App Checker against it. You don’t even need to be running Moblin anywhere – the app checker is a standard Linux app. The app checker will tell you which parts of your application are not compliant.

If you’re a new developer, go grab the Moblin SDK, and set up a Moblin development environment. (Or you can simply add a few extra libraries, like glade and clutter, to your existing Linux environment. Try to get your development to be as close to Moblin as possible, and use the compliance tools to see where you need to make fixes.)

The compliance tools, Spencer explains, gives you a red light if there’s a problem, telling you which libraries, you’re missing – or if you’re using the wrong versions. ISVs are required to use the lowest version of the library. For example, python 2.6 is required by the Moblin Compliance specs. If python 2.8 comes out, you'll still have to use python 2.6 in order to maintain compliance, because you can’t assume that the devices you’re targeting will have python 2.8.

Do-It-Yourself Certification

At the present time, there is no third-party certification process for Moblin OSVs or ISVs. Run the tools yourself, fix problems that occur and pat yourself on the back if you pass. Don’t look for a “Certified Moblin v2 Compliant” logo, though, for your hardware or software. “We’re still defining the process for official certification and whether a third-party certification process could help,” says Spencer.

The Future of Certification

You may have noticed that the version number of the Compliance Project is low – 0.6, as of early June 2009. That implies that there’s going to be more work going on over the next few months – and there is.

“We’re shooting for a nearly complete spec by early August,” says Spencer. However, until there’s a final version, using the tools will help you develop your application and platforms – but you can’t claim compatibility with Moblin in your marketing. With final versions of the draft spec and tools expected by early Fall, he says, “you can claim you're compliant with the spec.”

Until then, use the tools, monitor the Moblin newsgroups, and keep an eye on the Moblin Compliance Project page. {link to http://moblin.org/compliance}

* All names and brands are the property of their respective owners.


Alan Zeichick is principal analyst at Camden Associates, where he advises enterprises about technology challenges, writes for technology print and online publications and speaks at industry events on enterprise IT, networking, security, software engineering and consumer electronics. Meanwhile, as editorial director of BZ Media’s SD Times, Zeichick drives forward the industry newspaper for software development managers.

A former mainframe developer and systems analyst, Zeichick became a technology analyst and journalist in 1984. He has authored more than 3,000 articles, worked with consulting groups, including PricewaterhouseCoopers, IDC and Anderson Consulting, and has spoken at numerous events such as COMDEX, Networld+Interop, Microsoft TechEd, JavaOne and the Software Development Conference.

Read his personal blog at ztrek.blogspot.com.


Related Links

Moblin Compliance Project

Compliance Means Never Having To Say You’re Incompatible: Part 1

Linux App Checker Getting Started

Linux Standard Base

 

PDF RSS
PDF PDF
BESPRECHUNGEN SEHEN BESPRECHUNG SCHREIBEN TEILEN
  
[ Zurück ]
PARTNER IN DEN NACHRICHTEN
Nützliche Links:
Andere Projekte, an denen wir beteiligt sind
Midinux SDK download
Midinux Ready Program
Download hilfreicher Treiber
+ + Mehr...
NEWS
+ + Mehr...
Top Downloads
1
Moblin™ Quick Start Guide
2
Test Drive Moblin™
3
Moblin™ Live Image
4
Holen Sie sich ein MID-Entwicklungssystem!
5
Moblin™ Developer Tool Kit
Nächste Veranstaltungen
Intel®-Tools abrufen