Monday, June 25, 2012

Installed, but unpackaged files (debug ones)

When creating an RPM of some package this error might occur. Sometimes it does not make much sense as it lists only debug files as unpackaged.

In this case, it is most likely caused by invalid use of %exclude macro. Grr. I spent a bunch of time debugging this. HTH somebody.

Sunday, April 15, 2012

All TTY Drivers to Have tty_port

So the second pile of TTY patches have been accepted…

And now, the most of drivers in the tree was augmented to operate with tty_port structure. The only few remaining will be changed in the next merge window (a month or so). After that, every out-of-tree driver will be broken unless it is fixed right now. You have been warned.

One might ask, why we are doing this change? The answer is simple: The code is broken. Some of the code predates Linux 1.0. Yes, it is no argument, but you know what? It is full of ancient broken code designed originally for uniprocessor, no preemption and such. Thus there are many race conditions without any real chance to fix them in the state the code stands now.

And yet, Big-Kernel-Lock (BKL). You heard that it is gone from the kernel for some time already, right? No, it is not. It is still there. Some parts of the kernel still have left-overs from this ancient coarse-grained crap. In TTY, it is called Big-TTY-Mutex. And nobody really knows what is protected by the lock (and what is not). And as a reader may suggest, I volunteered to find out.

The plan is to centralize common code which is repeated over and over. This is done by using tty_port helpers. Next, we will move TTY I/O buffers from tty_struct to tty_port and revamp locking a bit. The move will also ensure that we will not need to care about tty_struct in a prevalent count of interrupt service routines, timers etc. They really need TTY buffers, not a structure which randomly comes and goes with every open and close the way tty_struct does. And since tty_port is in the memory intact as long as the device stays in the machine (and its interrupt service routine installed in the kernel), it is a perfect place to put the buffers in. And this is exactly what is happening here right now.

Stay tuned and report bugs!

Saturday, April 14, 2012

A Must-Have for Czech OpenStreetMappers

I collected the following URLs and find them useful when mapping: Besides these links, what is usually good to have is a GPS tracker. I use the one in my Nokia 5800 XM phone. Then It becomes handy if one has a bike to explore their hometown. And it really helps to have a (fast :)) motorbike to take a look at other cities.

Monday, March 19, 2012

Making ant work with antlr3 and cpptasks

When one uses antlr3 or cpptasks with ant, it might happen, that the following error occurs during build:
$ ant jar
...
.../build.xml:89: Problem: failed to create task or type
        antlib:org/apache/tools/ant/antlr:antlr3
.../build.xml:92: Problem: failed to create task or type
        antlib:net.sf.antcontrib.cpptasks:cc
The cure is (and always was) simple on openSUSE. One just needs to define OPT_JAR_LIST environment variable with appropriate jar names of packages where those classes are defined:
OPT_JAR_LIST='ant-antlr3.jar cpptasks.jar' ant jar

Tuesday, March 13, 2012

Adding a New Clang Checker

Create a file with checker, e.g. by making a copy of some other. Make sure you leave ClangSACheckers.h include in your checker.

Next, you need to add an entry to CMakeLists.txt and Checkers.td. Without that, you will not have your checker built or listed in clang checkers list respectively.

You may hit this build error:
error: 'void clang::ento::register...Checker(clang::ento::CheckerManager&)' should have been declared inside 'clang::ento'

In that case, check that you have ClangSACheckers.h included and that you did not misspelled filename in the two files above.

If the compilation is successful, you should see your checker in the clang checker list generated by:
clang -cc1 -analyzer-checker-help