Written by Hunter Jansen on November 10, 2014

It’s been about a week since my last post, I was hoping to get some progress on one of my porting projects to fill with content and future plans. However, things haven’t quite gone that way - so in this post, I’ll be explaining why that is, what the plan was and what’s actually happened.


Last time I talked about how I was planning on working on JSL and Snort to port them from x86 architectures to aarch64. I focused in on a couple spots in JSL that needed looking at that should be updated to work on aarch64 - there wasn’t much, but there was something to do. Since then, I’ve run into some difficulties with the package. After investigating the files, I decided to check out the upstream and discovered that the source was entirely different.

Where the package I was working with was mostly C with some perl and a python file or two, the current source was almost entirely in python. I decided to reach out to the upstream authors to introduce myself and see what the status is of the project, but after more than a week without a response, it was definitely time to move on.


So, my second package I’d decided to work on was snort. It’s not available via fedpkg and it’s not included in rpm due to some complex licensing that the software has. Snort’s a very widely used network intrusion detection software worked on by Cisco, so I was initially surprised that it was even on the list of software that needed updating.

After going through the relatively lengthy process of getting snort and its dependencies up on my x86 system and building it successfully, I looked at the embedded asm in the source: there was a lot. Sifting through it, I saw a bunch of references to iarch64 in the preprocessor defines. So, for fun I decided to go through the same process of installing Snort and its dependencies on aarch64.

After everything finished making and installing, I ran a few snort commands and a super simple ruleset. Low and behold, as far as I can tell, it works just fine without any changes required on my part. I couldn’t find any test suite to run, but all the basic functionality and a super simple ruleset worked just as expected. To write a test of my own would be pretty tough - I’d have to set up a network, set up snort on it and try to intrude upon it from a different machine.

Neat, that’s a project done on the linaro performance challenge, I guess!


Luckily I’d chosen fio as my backup project to work on, I’d looked at the source for it before in class and there wasn’t too terribly much to update. There was definitely some asm to take a look at, but it looked manageable.

However, since I’d been ‘burned’ so to speak with my previous two projects, I decided to go ahead and for the heck of it try installing fio on my aarch system using yum. Lo and behold, it installed just fine.

So, I decided to check it out and test some fio rules; everything looked like it was working to me, and just as performant as on my x86 system. I ended up testing about four of five rules before deciding it was safe.

I guess that’s another projet to say’s done on Linaro.


I’m just starting to look at a package on ubuntu called jsCoverage, which acts as a code coverage tester tool for javascript, much like php coverage or any other code coverage tool. As of this point, I haven’t yet had much success; I haven’t even found the repository for it yet, only the ubuntu repos. Hopefully I make more progress and actually find some code to investigate and hopefully update!

Until Next time -Hunter