Embedded, Kernel, Linux

Jumping the Kernel-Userspace Boundary – Procfs and Ioctl

I recently had a need to have a very fast and scalable way to share moderate chunks of data between my experimental kernel module and the userspace application. Of course, there are many ways already available. Some of them are documented very nicely here. I will be writing in a few blog posts sharing what all mechanisms I have used to transfer data and provide such interfaces.


I have used the Procfs before (with the seq_file API) when I needed to read my experimental results back in userspace and perform aggregation and further analysis there only. It usually consisted of a stream of data which I sent to my /proc/foo file. From a userspace perspective, it is essentially a trivial read-only operation in my case,

/* init stuff */
static struct proc_dir_entry *proc_entry;
/* Create procfs entry in module init */
proc_entry = proc_create("foo", 0, NULL, &foo_fops);
/* The operations*/
static const struct file_operations foo_fops = {
    .owner = THIS_MODULE,
    .open = foo_open,
    .read = seq_read,
    .llseek = seq_lseek,
    .release = single_release,
/ *Use seq_printf to provide access to some value from module */
static int foo_print(struct seq_file *m, void *v) {
    seq_printf(m, val);
    return 0;

static int foo_open(struct inode *inode, struct  file *file) {
    return single_open(file, foo_print, NULL);
/* Remove procfs entry in module exit */
remove_proc_entry("foo", NULL);


I also used ioctl before (More importantly, I call them eye-awk-till. *grins*). They are used in situations when the interaction between your userspace applicatoin and the module resembles actual commands on which action from the kernel has to be performed. With each command, the userspace can send a message containing some data which the module can use to take actions. As an example, consider a device driver for a device which measures temperature from 2 sensors in a cold room. The driver can provide certain commands which are executed when the userspace makes ioctls. Each commad is associated with a number called as ioctl number which the device developer chooses. In a smiliar fashion to Procfs interface, file_operations struct can be defined with a new entry and initializations are done in the module,

/* File operations */
static const struct file_operations temp_fops = {  
       .owner = THIS_MODULE,  
       .unlocked_ioctl = temp_ioctl, 
/* The ioctl */
int temp_ioctl(struct file *filep, unsigned int cmd, unsigned long arg) {
	switch(cmd) {
		copy_to_user((char *)arg, temp_buff, 8);
		copy_to_user((char *)arg, temp_buff, 8);

There are other complexities involved as well, such as using _IO(), _IOR() macros to define safe ioctl numbers. To know more about ioctl() call and how it is used, I suggest you read Chapter 7 from LKMPG. Note that newer kernels have some minor changes in code, hence refer to some device drivers using ioctls inlatest kernel releases. Each ioctl in our case means we have to use copy data from user to kernel or from kernel to user using copy_fom_user() or copy_to_user() functions. There is also no way to avoid the context switch. For small readings done ocassionally, this is an OK mechanism I would say. Consider that in a parallel universe, this sensor system aggregates temperature as well as a high quality thermal image in addition to each measurement. Also, there are thousands of such sensors spread across a lego factory and are being read each second from a common terminal. For such huge chunks of data accessed very frequently this each additional copy is a performance penalty. For such scenarios, I used the mmap() functionalty provided to share a part of memory between the kernel and userspace. I shall discuss more about Mmap in my next post.

Android, Java, Linux, UX/UI

QRite – QR Code Generator

UPDATE: Tanushri recently won a LG G Watch watch in PyCon 2015 (thanks to Google), so we have a watch to start implementing the smartwatch feature. The app will now be free on Google Play as well, as we don’t need money anymore 🙂

I had recently bought a smart-watch (SmartQ Z) and as mentioned in some of my previous posts, I started playing around and creating my own watch-faces. One fine day, I got an idea to put my contact details on the watch screen as a widget showing a QR code (with my vCard encoded) so that if someone asks me for my details, I could just flash my wrist and they could scan and save my contact info. Geek lvl over 9999.

So, I spent some a few evenings with a friend, re-inventing the wheel and created first my QR Code generation app. It was mostly an Android revision for us with some UX/UI brainstorming done now and then. The goal was to make it simple. Very simple. And clean. With just the necessary customizations given to the user. This is how it looks till now:


You can check out the beta attempt, get some more details and screenshots here : http://qrite.suchakra.in/ Its an open source app and if you want to use it or want to contribute to the source code, head over to this Github repo. The source is not so rosy and glorious considering I just focused on functionality and gave exactly 0 about anything else :/ It needs some cleanup for sure and it is indeed the next step.

So there are some features already available as configuring color, size and recent contact details for which QR code was generated. And some features are to be added, such as digitizing an already available QR code using your camera and ‘scanning’. The major feature, “Send to Smartwatch” is also left. The plans are to support Android Wear, Pebble and generic android (such as SmartQ Z) platforms. However, I don’t have Android Wear/Pebble for which this could be most useful. If you want to donate a Android Wear or Pebble (if you have one extra) or some money for me to get those, or if you just want to support open source development, you can consider buying the app from this Play Store link (it will be made free as soon as all features are completed). You can also send a donation by clicking 

Just FYI, my goal is approx USD $130 (price of cheapest LG W100 watch). Feedback and suggestions for the app are welcome.

TL;DR – Just another QR code generation app. Open sourced. Smartwatch integration in progress. Donate money for Android Wear/Pebble or submit code if you want.

Linux, UX/UI

Ask Fedora UX Redesign Updates #2

So taking into consideration most of the suggestions I had obtained during the recent Design FAD at Red Hat, the initial slides of desktop version are also ready. Maybe these are enough to start off with a basic CSS template which we can build upon iteratively while we work on more mockups for other major pages in parallel. Here is the updated mockup:

home-desktopJust a reminder that the color palette used here is not standard and its indicative. The standard Fedora color palette will be used in the code. The next mockups to be done are for the views for individual question pages, contributor/people page, the ‘ask question’ page and maybe the registration page if required. Most of the other stuff I think would be best done directly in the code. I was anticipating a bigger challenge in streamlining the design but personally I think, as Askbot apes the StackOverflow and similar Q&A websites’ UX to a large extent, the users already are familiar with flow of AskFedora. In any case, later on we can have something like this : http://askubuntu.com/tour – an Ask Fedora Tour page for beginners/new users so that the initial user-inertia reduces.

Contributions and comments welcome.

Linux, UX/UI

Ask Fedora UX Redesign Updates #1

The recently concluded Fedora Design FAD 2015 at Red Hat’s Westford office turned out to be quite productive where my idea of redesigning AskFedora user interface gathered some momentum. I met so many faces I had just always known as IRC nicks and above of all, enjoyed Sirko complaining to everyone for not playing Champions of Regnum that well during the gaming nights we had 🙂

So coming down to the point, I was joined by Zack (sadin) and Sarup (banas) for the initial redesign efforts. With their suggestions, I completed some high-fidelity mockups for the mobile and desktop interface intended to be used for Ask Fedora. As suggested by Sarup, we started with Mobile mockups first to get a simplistic view of user requirements. It can then be “stretched” for a desktop interface later on. After some feedback from Sirko, Emily, Mairin, Marie et al. here is a first mockup slide.

home-mobileTo get a context of changes, you will have to visit the current AskFedora instance and observe the changes. Newer slides and the desktop views are on the way. Even though this takes time, its important to have an idea of how you want your interaction with the application to be and FAD gave me a change to do some mockups before we dive into code and CSS. Which reminds me, that Zack and I managed to setup an Openshift repo of an askbot instance one night and would be mostly using it for testing out our design. (I also learnt Openshift awesomeness that night). Most of real usable UI updates will be posted on this repo : https://github.com/fedoradesign/askbot-test

Your comments and suggestions are welcome. More updates on the way.

Android, Embedded, Linux, UX/UI

Some Cool Retro Watchfaces

These holidays, I was refraining from spending huge sums on stocking gadgets I don’t need. But (un)fortunately, I ended up buying a Nexus 5, a Moga Hero controller and a cheap smartwatch. So what do you do when you get an Android device? Exactly! Start hacking on it – root, custom ROMs, custom kernel, cool apps! So, my experimentation started with the SmartQ Z Smartwatch I had bought. For the price (CAD $91, including shipping from China) this was an irresistible piece of tiny Android to start tinkering around with. It packs a 1GHz Ingenic processor (MIPS) – JZ4775, 512MB DDR RAM and 4GB flash. All of this with a tiny 1.54 inch screen with a 240×240 resolution. The latest firmware supplied by the vendor is based on Android 4.4 with a custom launcher. It is a very hacker-friendly device and came with ‘su’ out of the box 🙂 Though its a bit old (2013 launch) and the manufacturer seems to have abandoned the development on this, for the price, its a pretty impressive piece of tech on your hand.

I decided to make my own watchfaces with custom features and more inspiring UI than the watchfaces provided in the watch. Also, the hidden agenda was to check out the new Android Studio. As with everything Chinese, the SDK and docs for the Smartwatch were in Chinese! But fortunately, after surfing through XDA Developers forums, I found a link to the English docs on their website to refer to the weather APIs that I needed to use. With moderate efforts, I was able to make the following watch faces :

They are actually developed as widgets and the launcher apparently sees if the AppWidgetProvicer class you use starts with the string “WatchFace”. If this is the case, it simply puts that widget along with the custom watch faces in the menu.

If you own a similar watch/with similar screen dimensions, you can try installing the apps or use the source code for building your own cool watchfaces. I really wish I had an Android Wear watch rather than this so that I could develop on a more useful and up-to-date platform. Thanks for reading. Happy new year! Here is the source code and specs for these watch faces :

LCD Watch Face

Source : https://github.com/tuxology/LCDWatchFace

Download : lcdwatchface.apk

CRT Watch Face

Source : https://github.com/tuxology/CRTWatchFace

Download : crtwatchface.apk

If you find any bugs, report them on Github. Also, if you want me to port them on Android Wear, let me know. I’ll try to do that in emulator.

Kernel, Linux

Ease your kernel tracing struggle with LTTng Addons

If you are new to Linux tracing and/or LTTng, go no further. Head on to the new and awesome LTTng Docs to know what this stuff is all about. I wrote an article on basics of LTTng and then followed it up with some more stuff a few month back too.

Ok, so now for those who have been using LTTng for sometime and especially, the kernel tracer, I am pretty sure, you must have faced a moment when you would have asked yourself – what if I could just modify those default tracepoints provided by LTTng and maybe add some more functionality to them. As an example, here is an interesting use-case I recently encountered –

Consider the netif_receive_skb event. A tracepoint is present in a function of the same name in the kernel. This function notifies the kernel whenever the data is received in the socket buffer for any of the net devices and when this event in enabled, the tracepoint is hit and skbaddr, data length and device name are recorded by default. For more info on how this works, refer to the TRACE_EVENT macro in the kernel. There are a few articles on LWN explaining how this all works. The LTTng tracepoint definitions are no alien to this mechanism. They basically act as a probe to hook onto these tracepoints in the kernel and are provided in the form of kernel modules. Refer to the internals of lttng-modules package and do have a look at what LTTng Docs have to say about this. Coming back to our use-case, so now consider that I want to just record a netif_receive_skb event only when its a localhost device (skb->dev->name == "lo"). Hmm, interesting.

Now, instead of forcing you to understand the deep internals of how the LTTng’s macros were magically working behind the scenes, Francis Giraldeau did some little sorcery and churned out…*drum roll*… lttng-addons! Checkout the addons branch in the repo. Apart from a massive help in running research experiments rapidly, it can be used for some practical scenarios too. Do have a look at the current modules available in that. I have added a new netif_receive_skb_filter event (provided in addons/lttng-skb-recv.c) to explain the use-case which we were discussing about previously. It can also act as a mini template for adding your own addon modules. Basically the flow is – create your module C file, make entry in Makefile, add the custom TRACE_EVENT entry in instrumentation/events/lttng-module/addons.h for your module, build and install modules, modprobe your new module, fire lttng-sessiond as root and then enable your custom event. Such happiness, much wow!

Once you have built the modules and installed them, restart lttng-sessiond as root and try to see if your newly created events are available:

$ lttng-list -k | grep netif
netif_receive_skb (loglevel: TRACE_EMERG (0)) (type: tracepoint)
netif_rx (loglevel: TRACE_EMERG (0)) (type: tracepoint)
netif_receive_skb_filter (loglevel: TRACE_EMERG (0)) (type: tracepoint)

Do the usual stuff next and have a look at the trace:

$ lttng create
$ lttng enable-event -k netif_receive_skb_filter
$ lttng start
$ ping -c2 localhost
$ ping -c2 suchakra.in
$ lttng stop
$ lttng view
[22:51:28.120319188] (+?.?????????) isengard netif_receive_skb_filter: { cpu_id = 3 }, { skbaddr = 18446612135363067648, len = 84, name = "lo" }
[22:51:28.120347949] (+0.000028761) isengard netif_receive_skb_filter: { cpu_id = 3 }, { skbaddr = 18446612137085857024, len = 84, name = "lo" }
[22:51:29.120071966] (+0.999724017) isengard netif_receive_skb_filter: { cpu_id = 3 }, { skbaddr = 18446612137085856768, len = 84, name = "lo" }
[22:51:29.120102320] (+0.000030354) isengard netif_receive_skb_filter: { cpu_id = 3 }, { skbaddr = 18446612137085857280, len = 84, name = "lo" }

And there you have it, your first filtered kernel trace with your first custom addon module. Happy tracing!


Custom Kernel on Fedora 20

I recently stared experimenting with eBPF patches by Alexei Starovoitov which apparently are extending and restructuring the Berkeley Packet Filter infrastructure in the kernel. BPF is used for a lot of tasks like syscall filtering, packets filtering etc. and obviously deserves a separate and grand blog entry. Well, we’ll see what can be done about it later but for now, I’ll just explain how to do the trivial task of installing a custom kernel (possibly patched/upstream) on your Fedora machine. Its nothing grand, just those familiar textbook tasks. I am using the master from Alexei’s repo.

Build the kernel

git clone https://kernel.googlesource.com/pub/scm/linux/kernel/git/ast/bpf
cd bpf

I changed the EXTRAVERSION string in the Makefile just to differentiate it as I may have to use multiple versions while testing.

make menuconfig
make -j4

Set it up

sudo make modules_install
sudo cp arch/x86_64/boot/bzImage "/boot/vmlinuz-"`make kernelrelease`
sudo cp System.map "/boot/System.map-"`make kernelrelease`
sudo dracut "" `make kernelrelease`
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Restart your machine and enjoy the new kernel. Once you are done with the experiments, boot into the old kernel and remove the initrd, kernel image, and the custom system map. Then update the grub config once more. Thats it! I’ll post more about my experiments with eBPF soon.


[1] http://fedoraproject.org/wiki/BuildingUpstreamKernel
[2] http://broken.build/2012/02/12/custom-kernel-on-fedora