It’s nice too receive feedback about other architectures that we don’t have access, too. With kmod 3, sh4 joined the other architectures that were tested with kmod.

Since I’m already doing the announcements to the mailing lists, I’ll not repeat the NEWS here. Just look at the archives if you didn’t receive the email.

Happy new year!

I thank very much the feedback received for the first version and that now Jon Masters, the maintainer of module-init-tools, is helping us with kmod and already announced that kmod will replace module-init-tools in future.

I’d like to especially thank Tom Gundersen, Dave Reisner, Marco d’Itri, Jon Masters, Luis Strano, Jan Engelhardt and Kay Sievers who have been extensively testing kmod and helping with compatibility with previous tools. Right now kmod is tested in i686, x86_64, sparcv9, powepc64, s390 and ARM. More testers are greatly appreciated, especially for architectures not mentioned here.

News for this version are (copying from NEWS file):

Some bugs fixed: the worst of them was with an infinite loop when an alias matched more than one module.

• New APIs in libkmod to:
• Get soft dependencies
• Get info from module files parsing ELF
• Get modversions from files parsing ELF
• Support to load gzipped kernel modules: kmod can be compiled with support to  gzipped modules by giving the –enable-zlib flag
• Support to forcefully load modules, both vermagic and modversion
• Support to force and nowait removal flags
• Configuration files are parsed in the same order as modprobe: files are  sorted alphabetically (independently of their dir) and files with the same name obey a precedence order
• New tool: kmod-modinfo
• kmod-modprobe gained several features to be a 1:1 replacement for modprobe.  The only missing things are the options ‘–showconfig’ and ‘-t / -l’. These  last ones have been deprecated long ago and they will be removed from  modprobe. A lot of effort has been put on kmod-modprobe to ensure it maintains compabitility with modprobe.
• linux-modules@vger.kernel.org became the official mailing list for kmod

For the next version, we plan to migrate our git repository to kernel.org. Meanwhile, git repository can be found at http://git.profusion.mobi/cgit.cgi/kmod.git/ and packages at http://packages.profusion.mobi/kmod/

It’s now fixed in git tree. Thanks to Ulisses Furquim for fixing it and Dave Reisner for the bug report. We already have some other great stuff implemented so we’ll soon have another release.

Another great news is that now we have the maintainer of module-init-tools (Jon Masters) cooperating with us. We will discuss how the two projects will co-exist/merge. So, for now on the official mailing list of the project is linux-modules@vger.kernel.org.

Overview

The goal of the new library libkmod is to offer to other programs the needed flexibility and fine grained control over insertion, removal, configuration and listing of kernel modules. Using the library, with simple pieces of code it’s possible to interact with kernel modules and then there’s no need to rely on other tools for that. This is a thing lacking on Linux for a while and it’s one of the items in the Plumber’s Wish List for Linux. Quoting it:

provide a proper libmodprobe.so from module-init-tools:
Early boot tools, installers, driver install disks want to access
information about available modules to optimize bootup handling.

We went one step further and not only we are able now to give an API to load and remove kernel module, but also all the other common operations are being added to this API. The first user for this API will be udev. In a recent Linux Desktop (and also several embedded systems) when computer is booting up, udev is responsible for checking available hardware, creating device nodes under /dev (or at least configuring their permissions) and loading kernel modules for the available hardware. In a kernel from a distribution it’s pretty common to put most of the things as modules. Udev reads the /sys filesystem to check the available hardware and tries to load the necessary modules. This translates in hundreds of calls to the modprobe binary, and in several of them just to know the module is already loaded, or it’s in-kernel. With libkmod it’s possible for udev with a few lines of code to do all the job, benefiting from the configurations and indexes already opened and parsed. We’ve been talking to Kay Sievers (udev’s mantainter) and Lennart Poettering (systemd’s maintainer) regarding this and we are looking forward to have udev using libkmod soon.

Example code:

To insert a module by name without any options and strange configurations it’s sufficient to do as following (without treating errors for easy of comprehension – see the documentation for possible errors):

	struct kmod_ctx *ctx = kmod_new(NULL, NULL);
	struct kmod_module *mod;
	kmod_module_new_from_name(ctx, name, &mod);
	kmod_module_insert_module(mod, 0, NULL);
	kmod_module_unref(mod);
	kmod_unref(ctx);

Tools

Besides doing the library, we are re-designing the module-init-tools tools on top of the new API we created. With this first version we are already providing compatible binaries for lsmod, rmmod, insmod and modprobe, the last one with some functionality missing. Next versions we plan to fill the gaps with the provided tools and provide all the others like depmod and modinfo.

License

We try to avoid issues regarding licences: the library is licensed under “LGPLv2 or later” and the tools are under “GPLv2 or later”. There’s still lots of work to be done and places to optimize. We greatly appreciate contribution from other developers.

Roadmap

The API is not set on stone and is going to suffer some changes in future releases as we see fit to finish implementing all the tools. Below is the list of the features already implemented

kmod 1

libkmod provides the necessary API for:

• List modules currently loaded
• Get information about loaded modules such as initstate, refcount, holders, sections, address and size
• Lookup modules by alias, module name or path
• Insert modules: options from configuration and extra options can be passed, but flags are not implemented, yet
• Remove modules
• Filter list of modules using blacklist
• For each module, get the its list of options and install/remove commands
• Indexes can be loaded on startup to speedup lookups later

Tools provided with the same set of options as in module-init-tools:

• kmod-lsmod
• kmod-insmod
• kmod-rmmod
• kmod-modprobe, with some functionality still missing (use of softdep, dump configuration, show modversions)

Following is a rough roadmap for future releases:

kmod 2

• Provide the API for features missing in kmod-modprobe, namely: dump configuration and indexes, soft dependencies, install and remove commands. Features relying on ELF manipulation will still be missing;
• Provide all the tools available in module-init-tools. Some of them like depmod may be entirely copied from module-init-tools for later convertion;

kmod 3

• Provide a single kmod tool that will abstract all the others, accepting commands like “kmod list”, “kmod remove”, “kmod insert”. Distributions may then use symlinks from current tools to the kmod binary and we can kill the ‘kmod-*’ test tools that we are introducing in kmod 1;

We thoroughly test the features implemented in kmod, but like any other software it’s possible to contain bugs that we didn’t find; we may decide to release new versions between the versions above and then this numbers change. Otherwise kmod 2 will already be sufficient for udev to pick it up as a dependency and start benefiting from the fine grained control over its operations with kernel modules.

Repositories

The repository for this project is located at http://git.profusion.mobi/cgit.cgi/kmod.git/

Package with kmod 1 source code can be downloaded from: http://packages.profusion.mobi/kmod/

Thanks

Last I’d like to thank Kay Sievers for his support in reviewing code, giving advices and helping to design kmod.

I’m using the Socialize plugin in WordPress. I’m not sure if it’s the best one: I just installed and checked it works. Any advices?

EDIÇÃO 02/12/2011: coloquei uma nota no slide 7, relatando o que falei durante a apresentação sobre uso de IDE.

Para aqueles que não conseguem visualizar acima, segue o link direto para a apresentação.

It was also a great time to talk again to some developers I met in LinuxCon Europe last month and some that were not present there. One talk I really like was given by Eugeni Dodonov about the Intel Linux Graphics stack. It was a good overview of all the graphics stack in Linux, paying attention to Intel’s boards and drivers. Gustavo Barbieri talked about HTML5 and WebKit and other 2 ProFUSION’s employees — Rafael Antognolli and Bruno Dilly — presented “Application Development using Enlightenment Foundation (EFL)”

This time I also gave a presentation entitled “How to become an open source developer”. My focus was on the Brazilian crowd out there, willing to start to contribute to open source projects, looking for a job or just trying to understand why we do open source development. I hope it was useful for them and for you reading this blog, too. So, below are the slides of my presentation:

For those of you who can not see the file embedded above or want the direct link, here it’s in PDF format.

I also talked to some important people regarding a new project of mine. Stay tuned for a new library soon.

Starting from Kernel Summit, I had the opportunity to join the Bluetooth Summit and participate in the discussions regarding this subsystem in Linux, both in kernel and user space. We had a lot of hot topics to discuss, including the upcoming BlueZ 5.0, Bluetooth 3.0 (high speed), Bluetooth 4.0 (low energy) and I could also demonstrate the work I’ve been doing with the AVRCP profile. I’m glad it received a good acceptance from other developers. Some of them I didn’t know personally such as Luiz von Dentz, Claudio Takahasi, Vinicius Gomes. Others I had the pleasure to meet again like Marcel Holtmann and Johan Hedberg.

(We didn’t discuss only bluetooth related things. We noticed that more than 1/3 of the people there, working in the core of Bluetooth in Linux, was Brazilian and soon we were discussing with Samuel Ortis – a French, maintainer of ConnMan – who is the best soccer player .)

Daniel Wagner from BMW also brought up some interesting scenarios of multiple devices connected through Bluetooth in car kits and helmets (like this one): HFP, A2DP, HSP (and maybe also AVRCP?). All of them interacting and working together at the same time. Since the gstreamer conference was also taking place at the same facility we could also discuss with PulseAudio developers. In the end, it seems BlueZ and PulseAudio are working pretty well together, though we still have to polish some rough edges for some use cases like this.

Being at Kernel Summit was a great time to meet developers of other parts of the kernel too, such as Steven Rostetd and Peter Zylstra, with whom I had more contact some time ago when I was working in the Linux scheduler.

When the Kernel Summit was over (on Tuesday), LinuxCon and ELCE were taking off. It was great to have once more these two conferences collocated and being able to attend talks on both of them. There were several talks I’d like to attend but some of them were overlapping. I’m looking forward to see the recorded talks later this year[1]. It would be too extensive to detail each one here, so I’m just detailing some of them that grabbed more attention from me.

Gustavo Barbieri and Sulamita Garcia talked about Demistifying HTML5 and how it can be used to develop Apps. Gustavo focused on the EFL port of WebKit (in which I’m one of the developers ) and the underlying technologies. It seems like the mentality of “let’s do apps in a very high-level language” instead of “providing a native language in a sdk” is coming back. Differently from what happened some years ago, this time maybe it will work out. Only future will show us.

Since this year I got involved with Android and development of the platform, I went to several Android-related talks. Leveraging Android’s Linux Heritage was really good stuff, showing how to replace some parts of the Android platform: bash instead of the I-wanna-be-a-shell that comes with Android by default, putting gstreamer in, optimizing some parts of the code, etc. In the same tune there was another talk entitled Build Community Android Distribution and Ensure the Quality. Interesting (but not surprising) to see how hard is to contribute to AOSP and how Android is much different from other open source projects we are used to.

Another interrelated areas that I have interest in (maybe because I work for a company related to embedded systems ) are system initialization, fast boot and development boards (such as Pandaboard). Therefore I attended systemd Administration in the Enterprise and Integrating systemd: Booting Userspace in Less Than 1 Second. The former, given by Lennart and Kay, focused on detailing some systemd features for guys running enterprise servers while in the latter Koen told us about his experience reducing boot time by using systemd in a Pandaboard. In this last talk I also met Jean Christophe, one of the developers of barebox (a bootloader aiming to replace U-Boot). Last time I checked, pandaboard was not in the list of supported boards but I was greatly surprised that now it is. Barebox has the advantages of running with caches enabled, having an architecture much more beautiful and being much faster than u-boot. In summary, IMHO it’s a bootloader done right.

Other interesting talk was Tuning Linux For Embedded Systems: When Less is More, in which Darren Hart gave instructions to reduce boot time and image size in very resource constrained scenarios (he was aiming a rootfs of only 4MB and total boot time under a second). Some key things to know is how to investigate what is not important to the application, what can be removed from kernel/userspace in order to fit the requirements and when to replace, why to replace and what to replace. Last but not least, in Developing Embedded Linux Devices Using the Yocto Project and What’s new in 1.1 David Stewart gave a status quo of the Yocto project. Interesting how the project evolved over this year and next time someone doing embedded systems think about ruling out its own distro from scratch, it would be good to look at Yocto.

I met a lot of other people for whom I apologize not citing their name here. This post would be yet bigger than it already is. I had a really great time their and I hope to continue going to these conferences. And the next one is LinuxCon Brazil, in which I’ll talk about How to Become an Open Source Developer. I look forward to seeing all of you there.

I’d like to thank the Linux Foundation for organizing such a great event and ProFUSION to allowing and sponsoring me to be there.

Side note: the problem is that now I want to do a lot of things in different projects without having time to to: systemd, Linux kernel, BlueZ, pandaboard, barebox, Android, etc

[1] UPDATE: videos have been published - http://free-electrons.com/blog/elce-2011-videos/

Technical background

For those who don’t know what I’m talking about, here comes a little background for those buzzwords:

BlueZ is the user-space part of the Bluetooth® technology stack used on Linux and Android. It has support for several Bluetooth profiles such as RFCOMM, HID, PAN, PBAP, OBEX, HFP, A2DP (some of them are implemented as separate projects) that are defined by the Bluetooh SIG. In simpler terms, BlueZ is what allows your Linux device to do amazing things with Bluetooth technology such as stream stereo music, make phone calls and other wireless magics.

One of these profiles supported by BlueZ is AVRCP (Audio/Video Remote Control Profile), which allows two devices to communicate through Bluetooth technology and exchange commands/messages to control the music/video being played.

New features

Until some weeks ago BlueZ only had support for version 1.0 of the AVRCP protocol. This early version allows a Controller device (e.g. a Bluetooth technology-based car kit) to tell the Target device (e.g. a smartphone) to play, pause, go to next music and go to previous music. We’ve now upstreamed an implementation of AVRCP Version 1.3, which adds some nice features to the previously supported version, such as:

• Transmitting metadata of the music being played;
• Change Application Settings such as Equalizer, Repeat, Shuffle and Scan modes;
• Set current status of media playback: playing, stopped, paused, forward-seeking, reverse-seeking.

Some time ago I bought a Bluetooth stereo car kit. How boring it was having the ability to stream music from my phone but not see any information regarding who was playing, which album, etc. This is no more. Now we have proper support for AVRCP 1.3 . Our ProFUSION team utilized the open source baseport for the OMAP™ processor-based Blaze™ mobile development platform from Texas Instruments Incorporated (TI) to help achieve this milestone. Additionally, we worked together with TI on testing and debugging to make this AVRCP 1.3 support a reality. Below you can see yours truly holding a Blaze™ mobile development platform from TI, sending music metadata to a Bluetooth technology-enabled car kit.

One of the issues I with codespell was that it was trying to parse cscope.out, since it’s a text file. On Linux Kernel this file can get very big and besides taking much longer, sometimes it was running out of memory . Now codespell has an option to ignore files, even text ones. It’s as easy as passing –skip=”*.eps,cscope.out” (notice this is useful for ignoring eps images too). Another useful thing (not much for Linux Kernel though) is proper detection of encoding by using chardet.