Sunday, February 25, 2018

wic in yocto

As of the time of writing the manual of wic in the the Yocto Mega manual has a massive omission. It only explains how to use wic individually and does not talk about the IMAGE_FSTYPES = "wic". Because of this if you ran wic create you will get strange errors like.

Please make sure wic-tools have %s-native in its DEPENDS, bake it with 'bitbake wic-tools'

This message will not appear if you set IMAGE_FSTYPES = "wic", because the IMAGE_DEPENDS_wic already contains the above dependencies.

Also with the IMAGE_DEPENDS_wic_append_${MACHINE} you can deploy boot packages which wic could required to create the images.

PS: I hate blogger interface.

Edit: While grepping my poky I found that the included documentation refers to exactly what I wrote above. Well may be some googler will find it useful.

Wednesday, February 21, 2018

Nice trick to diagnose gcc search paths

Recently I needed to use a compiler as part of an sdk and needed to point it to the correct sysroot. For some reason the --sysroot flag did not work correctly. To inspect what was going on in gcc 'mind' a colleague told me about a "trick":

gcc -o  ./g.c -E  -P  -v -dD

Wednesday, October 04, 2017

External Source kernel modules install does not fail as it should

Another small post to serve for future memory that when you are building Linux Kernel modules from external tree source, the kernel build system behaves differently. Yesterday it happened that I lost a huge amount of time trying to understand why the installation of a module was not exiting with error, when I clearly saw errors in the logs. The reason is that this is on purpose. In the build scripts for kernel installation there is this hidden gem: https://github.com/torvalds/linux/commit/f6a79af8f3701b5a0df431a76adee212616154dc Don't stop modules_install if we can't sign external modules. I have been warned.

Monday, August 28, 2017

ParseError not a BitBake file

This error occurred to me when I made a require or include with the path to the file inside " quotation marks. The error message of course just said that  

ERROR: ParseError in "conf/machine/include/tune-cortexa53.inc": not a BitBake file

Solution: Remove the quotation marks around the file path in any require or include directives.

Tuesday, July 18, 2017

A script that pause/plays on lock/unlock Spotify

A script that pause/plays on lock/unlock
#!/bin/bash

dbus-monitor --session "type='signal',interface='org.gnome.ScreenSaver',member='ActiveChanged'" | \
(
  while true; do
    read X
    echo $X
    if echo $X | grep "boolean true" &> /dev/null; then
        dbus-send --print-reply --dest=org.mpris.MediaPlayer2.spotify /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.PlayPause
    elif echo $X | grep "boolean false" &> /dev/null; then
        dbus-send --print-reply --dest=org.mpris.MediaPlayer2.spotify /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.PlayPause
    fi
  done
)

Sunday, May 07, 2017

readlink system call fails on other files besides symbolic links

I just write this post to remind myself that the readlink system call fails on non symbolic links. I was expecting that it would work on files and directories but it doesn't.

man 2 readlink says in one of the errno:

EINVAL The named file is not a symbolic link.

So the next step is to check if the path is a symbolic link or not. The first choice would be to use stat on the path, but stat will give you results from the dereferenced file, not the symbolic link. So using stat system call on a file will never tell you if the file is a symbolic link.

lstat()  is  identical  to  stat(), except that if pathname is a symbolic link, then it returns
       information about the link itself, not the file that it refers to.


There you have it for future reference:

std::string MountHandler::doReadlink(std::string const& path) {
    char buff[PATH_MAX];
    struct stat stat_buf = {};
    if (lstat(path.c_str(), &stat_buf) == -1)
        throw std::runtime_error(fmtString("Could not stat path %s. Errno: %s",
        path.c_str(), strerror(errno)));

    if (!S_ISLNK(stat_buf.st_mode))
        return path;

    ssize_t len = readlink(path.c_str(), buff, sizeof (buff) - 1);
    if (len == -1) {
        throw std::runtime_error(fmtString("Readlink failed on %s. errno %s",
            path.c_str(), strerror(errno)));
    }
    buff[len] = '\0';
    return std::string(buff);
}

Sunday, April 16, 2017

Breaking abstract class interface in C++

Today while working on some code I had the need to make a tiny-bit-small break on a contract from an abstract base class.

The case is that I had an abstract base class called Pin, that contracted 2 methods for subclasses. The problem is that the InputPin class while benefiting from other functionality provided by the class Pin, could not sensibly provide a setPinValue method. Imagine I am naive and will only inform this operation is impossible on runtime:

volatile bool pinA1 = false;

class Pin {
public:
 virtual void setPinValue(bool value) = 0;
 virtual bool getPinValue() const = 0;
 virtual ~Pin() {}
}

class InputPin : public Pin {
public:
 virtual void setPinValue(bool value) { throw std::runtime_error("Cannot set value on input pin"); }
 virtual bool getPinValue() const { return pinA1 };
}

class OutputPin : public Pin {
public:
 virtual void setPinValue(bool value) { pinA1 = true; }
 virtual bool getPinValue() const { return pinA1 };
} 

Then I set out to find if I could use the compiler for my help in such a case. As usual Stackoverflow had question and answer about it. The answered marked as right is the ideal answer: No you cannot delete Pure Virtual Methods, fix your design. A bit further down showed the real answer: You can achieve something similar but it is not advised:

class InputPin : public Pin {
public:
 virtual bool getPinValue() const { return pinA1 };
private: 
 virtual void setPinValue(bool value) { throw std::runtime_error("Cannot set value on input pin"); } 
}


Just encapsulate the breaking method in the private part of the class and no one will be able to use it. If the Older-You gets the idea of using it in some private part of your own implementation you still get the luxury of the exception

I like answers who say "You kind of can do it, but you shouldn't", because you get to learn the corner cases and tricks with which to shoot yourself in the foot some time later. I, like everyone else, like a corner trick to impress the girls. Of course some time later it bites me back, or just my Older-Me looks back with astonishment at such a pretentious idiot I was.

*EDIT* After thinking a bit more about it and talking with my friend about it, he came up with the idea that just hiding the method in a private part of the class is not enough to make it reachable. This is because if the class is called polymorphically the virtual dispatcher in run-time will still reach this hidden method.

The best way in the end is to make it private and do nothing.

TLDR; Redesign your architecture to not have broken interfaces.