YES!! We are going, are you?

Av Johan Deimert den 20 Augusti 2015

As the title says, Linux Development Center will be going to Dublin in October to  attend Embedded Linux Conference Europe.

What can be expected? A lot of embedded Linux experience that hopefully can be applied to our own project and to feed new thoughts on how things could be done.

As there are a number of parallel conferences on Linux there are a lot of seminars to choose from, reading from the schedule there are a large variety of fields. How ever, after a small glance there seems to be a overweight that has to be with connectivity. Also some robotics and drone stuff, which were a large part of the Embedded Linux Conference held this march in San Francisco. This was called ”Drones, Things and Automobiles” which points in the direction that the Linux dists are going.

See you there!

Eudyptula challenge

Av Marcus Folkesson den 30 Juli 2015

For those who never heard about the Eudyptula Challenge, it is a series of programming tasks for the Linux kernel. The format of these exercises is inspired from the crypto-challenges that has been around for a while.

Before we go any further we need to sort out one thing that I know you are thinking about, why chose a name that is so hard to spell to and impossible to pronounce as Eudyptula?
When signing up for this challenge, all communication is done by mail with Little, who is ”a set of convoluted shell scripts that are slow to anger and impossible to debug”. Eudyptula is latin for the smallest species of penguins, and there is the connection.

To join the challenge, all you need is to send an email to Little and tell that you want to participate. This requires that you have a sane email-client, which surprisingly few have. Nasty things such as HTML in emails are totally forbidden, noone wants it anyway, and it will be rejected from all kernel mailing lists.
I personally use Mutt for all my emailing.

There are currently 20 tasks starts from a very basic ”Hello world” kernel module and moving up in complexity. A couple of tasks is to get patches accepted to the main Linux kernel source tree which involves some ”real work”, interact with people on the mailing list and get to know the development procedures for the Linux kernel.

But what do you need to know to take the challenge?
A basic understanding of the C programming language is required, that’s all.

I have been doing Linux kernel development for quite some time but I have learnt a lot. Mostly because I have not had reason to touch areas such as the implementation of the FAT filesystem, get my modules to load automatically when I plug in an USB keyboard or write a netfilter hook to search all incoming TCPv4 packets for a specific ID.
As you see, the tasks is touching many parts of the Linux kernel. The tasks also cover really useful parts such as using DebugFS, create sysfs entries, make character devices and so on.

One side effect is that you will be good at using Git (I really do love git..) since you will be using it a lot. But one of the biggest earnings of taking this challenge is that you will be really good at navigating in the Linux kernel source code, which is necessary when doing kernel development. The concepts in the kernel stands, but the implementation vary with versions and so will the internal API, so you have to lookup code all the time. Fast navigation will facilitate for sure.

Personally I use VIM as editor with plugins for cscope/ctags/global for fast navigation and it works like a charm, really.
A tips is to use ”git grep” for searching within the project, it is much faster than a recursive ”grep” since it only searching in files which is part of the repository (not searching auto-generated crap).

I hope you find this challenge interesting and you give it a chance. The time is well spent if you ask me, and it will take time. The challenge will require a lot of studying and reading source code, but let it take the time it needs, this is no race.

See ya on the lkml!

PS: Here is just a quote from a random mail in my inbox… :-)

Very nice job, you are now done!
If you were curious, you are the 102nd person to complete the series of
tasks, with over 11000 people currently attempting it.

ldd without ldd

Av Marcus Folkesson den 14 Juni 2015

I sometimes meet colleges at work who gets frustrated when they try to print the shared libraries dependencies for an ELF or library, and the ldd command is simply stripped out from target. (I do often strip targets :-) )

As if that would be a big problem.

The ldd command is not a binary executable, but a script that simple calls the runtime dynamic linker with a few environment variables set, and you may do the same!
The essential environment variable in this case is LD_TRACE_LOADED_OBJECTS, that should be set to something != 0.

In short, you may do:
LD_TRACE_LOADED_OBJECTS=1 /lib/ ./my_application.

Even the –list option may be used, but does not work on all targets.

/lib/ --list ./my_application.

Example outputs with ldd:

[11:16:58]marcus@tuxie:/tmp/a$ ldd ./main =>  (0x00007fffc8bff000) => /lib/x86_64-linux-gnu/ (0x00007f564e254000) /lib64/ (0x00007f564e647000)

Example output without ldd:

[11:17:23]marcus@tuxie:/tmp/a$ LD_TRACE_LOADED_OBJECTS=1 /lib64/ ./main =>  (0x00007fffeecbc000) => /lib/x86_64-linux-gnu/ (0x00007fcce7700000) /lib64/ (0x00007fcce7af3000)

So, do not get frustrated, be happy.

Apple och öppenhet

Av Mats Sjövall den 8 Juni 2015

Haha, jag måste bara kommentera att Apple idag utannonserade att dom skulle OpenSource:a Swift. Lite skämtsamt förutspådde jag detta för ett år sen i en tidigare bloggpost och man kan faktiskt se en trend att de stora företagen slåss om oss utvecklare genom att göra oss delaktiga i deras produkter på ett sätt vi inte sett förrut. Jag tycker det är en mycket positiv trend och detta fick mig lite mer nyfiken att kolla närmare på Apple:s utvecklingsplattform.

What is your workflow strategy?

Av Johan Deimert den 31 Maj 2015

Have you ever thought of that? And additionally, how well does your working environment support your preferred workflow?

Me, for starters, have always been a great fan of the Visual Studio Development Environment. Primarily because this was the first encounter with an IDE that was setup for a large project, this was VS 6.0 and I worked as a contractor at Sony Ericsson Mobile Communications. I learned a lot about VS and how it could work with some carefully selected or written plugins.

And what I have come to realize is that what I really like about VS is the debugger and its environment. In my opinion hands down still the best debugger.

Fast forward and a lot of the later projects that I have been running has involved stuff that are not targeted for the Windows environment, i.e. setting up VS to work correctly is harder and sometimes impossible. So if I cannot have the functions as I want in an IDE how do you do it?
Well, some sort of text editor, cross compiler environment with Makefiles, a serial port and hopefully some gdb connection to be able to some decent debugging.

What this means for me and my workflow is when I start up the computer and log in I running my ”super-special-delux-script” that opens a number of terminals, some sort of light weight editor e.g. Geany and a web browser. All spread out over the virtual desktops. And usually there are some additional terminals opened along the way as well as some more editors, some remote desktops and puuhhh.

Some of you might say that Eclipse is the answer, I say meh… Every time I try Eclipse for a new project I get mad and I know why. The first encounter that I had with Eclipse and setting up a cross compiler environment was really bad and the person that was there to help me even worse. And that is still in my head many years later.

My new strategy is however to try to do things based on the terminal. So my new workflow strategy for development in Linux environment is:
- the i3 tiling window manager
- VIM, setting it up with the help found on Ben McCormick – Learning VIM
- new file structure on disk
- really trying to learn and understand gdb and gdbserver

It is coming along very nicely :-)
The best improvement I have noticed at this point is the i3 tiling windows manager, I think this has done some wonders for my workflow. And as a step to be more fluent in VIM I have changed the key layout to better map VIM keys. And taking it one step further installed the Vimium App in Chromium (installation link). So there is no excuse to not just the keyboard instead of the mouse. This is also a workflow strategy, training the muscle memory.

I still do use Eclipse for some projects, but if its sole purpose is the be a code editor I try to run VIM and get used to the interface.

Running for a trial period as of now I use the Jetbrains CLion, a code IDE that uses CMake to build the project. And I hope to use that IDE some more as well.

Tip of the day

Running i3, VIM and Vimium and other keyboardcontrolled applications the ESC key is to far off and I will have some pain in my left pinky at the end of a code intensive day. So I have, like many, many, many others before me, remapped the useless CAPS LOCK key to act as ESC.

# vim .i3/config

Add the following line some where in the end:

exec –no-startup-id ”setxkbmap -option caps:escape”

And Save

To next time, have a good one!