Having in place a setup that allows remote access to your development machine – which most probably is located at your work place -, has many advantages. Not only does it prevent duplicating equipment (e.g., having a decent set-top box at home), but it enables the possibility to get work done when travelling. However, some times it is desirable that such development machine is only available from a local network. It is in these cases that reverse ssh tunnels come handy.
Lately, I am spending quite some time verifying Open-Cannel SSD hardware prototypes in the context of LightNVM. A great deal of these tests is about benchmarking performance (iops) and latency, for which I use fio. Fio is a great tool to test specific I/O patterns. However, when wanting to benchmark a range of I/O configurations in different setups, it is very convenient to automatize the process. In this post, I present a simple python script that allows to automatize fio tests as a function of block size, number of jobs, I/O depth, etc. and stores the test results in csv format. Also, in order to account for variances, the script supports replicating each fio test a configurable number of times, being the average of these the one being stored.
I use my MacBook as my main machine from which I access daily a number of servers that I use for development, experimentation, and maintenance. Since I do all my job from the terminal, I end up using SSH extensively. One major issue I have encountered is that SSHing different servers entails (i) having a mental map of which terminals correspond to which machines, and (ii) the overhead of introducing a SSH line immediately after opening a new terminal window. Although this can be mitigated by merely using zsh’s substring history search, aliases, etc., I found it easier to offload the responsibility to my muscle memory. In this post, I will describe my setup which, after over a month of being in production, has proved to make my life easier.
I use vim for development. More concretely, I use YADR, a fork of dotfiles for my zsh, git, vim, etc. setup. One of the vim plugins that I use the most is neocomplete, which provides simple but powerful autocompletion. One of the last commits in neocomplete introduces a problem that impedes correctly wrapping lines – normally set to 80 characters (issue here). It turns out that it was vim, not neocomplete that triggered this unwanted behaviour. This vim patch, fixes the issue, but the binary cannot be obtained for neither MacOS nor Ubuntu – which are my main OSs – via standard repositories. Thus, I decided to find a way to keep my vim updated so that I can easily patch future problems.
The other day I came across a memory leak in a char device driver I am implementing for the Linux Kernel. While in user space one can make use of Valgrind (see post), kernel space is not that simple to monitor. Instead, one can use kmemleak, a memory leak detector embedded in the kernel which, among other architectures, supports ARM. In this post I will cover one minor configuration obstacle that one must overcome to get kmemleak to work on the Zynq ZC702.
While having an updated version of OpenSSL is always recommended, vulnerabilities such as The Heartbleed Bug reported 7th of April 2014 reminds us of it. Also, not counting on an updated version can cause some packages not to install (e.g., IO::Socket::SSL, necessary to run git send-email). In this post we go through the steps of updating OpenSSL in OSX, which as usual, entails a few more steps than in linux. I use Homebrew as a package manager.
Open Virtualization (OV) is the first open software implementation of a Trusted Security Environment (TEE) for ARM TrustZone hardware security extensions as specified in Global Platform’s TEE Specification.. Sierraware is the company behind it. Since I first knew of OV I have had a great interest in using it for my research, and therefore I have spent some time understanding it and improving it to work with the boards we work with – the Xilinx’s ZC702. This efforts are now materialized in a git repository, under a GNU v2.0 License.
As most of my post containing tips, this one is also about how to integrate MacOS with a proper Linux developing environment without introducing a big overhead. The obvious question here would be: Why don’t you fully move to Linux and forget about having to integrate your everyday OS with your developing environment? Well, we all have our preferences and motives, which are not the goal of this post. For those who use a similar setup as mine here comes good news: Parallels 9 successfully approaches one of the biggest issues I have found when dealing with Virtual Machines (VMs) under MacOs: Sharing the file system between the host and the guest machines.
Dealing with dynamic memory is a very demanding task in low level programming languages like C, where the flexibility of the language is build on top of the assumption that programmers do not make mistakes, but they (we) know what they are doing at all times. As Peter Van Der Linden masterfully writes in this Expert C Programming book: “It’s not a bug. It is a language feature”. (if you have not read the book, but it. Now!). In this post I will present one of my favourite programming tools: Valgrind, which helps programmers (among other things) to deal with memory leaks in their programs.
If you use Mac OS for development and have ever experienced that cloning a GIT repository produces instant non staged changes for commit then this is your post. Here I will explain the underlying problem for this GIT weird behaviour and propose 2 solutions: (i) lazy i-don’t-want-to-format-my-mac, and (ii) I want to do things right. So, let’s get started.