Parsing the Linux procfs

I’m writing C++ code for Unix environments for almost a decade now.

And the funny thing is that in the last five years, while working for three different companies, I had to write a new procfs parsing library every time.

All those companies were developing security products monitoring applications running on Linux machines, so using the procfs was inevitable.

But over time, necessity became great admiration. I simply grew very fond of the amazing creation called procfs.

Having the honor of writing Linux kernel code that exported values using the same mechanisms, I also experienced the other end of things and liked it even more.

Since I haven’t read many blogs posts from library authors, and it’s been a while since I got to writing, I decided to document the mental process I was going through.

Hopefully it will make for an interesting reading or better yet, expose me to readers and ideas I can learn from. This blog post is all about me writing the pfs  library, the decisions I’ve made and why I made them.

Styling

I try to be true to myself and admit to the faults I’m aware of. One of those is a “slight” OCD. For example: Looking at a standard-sized screen with 60 lines of code in scope, I can easily loose focus over some misaligned lines.

It bugged me when I started coding, it bugs me at work and it will probably always bug me.

I believe that a huge part of our ability to percept and understand code relies upon our subconscious’ ability to sync with what it sees and know what to expect.

That is why any coding standard is always better than no standard.

I’ve seen great developers throw away hours trying to read and understand code that was simply formatted differently than what they were used to (No, not the ones that do code reviews with IDA).

And for those of you that make fun of that, just remember great developers are usually structure people with very developed logical skills.

To make use of those skills, one has to make sure that all the pieces come together nicely.

All in all, I decided to prevent this issue from ever happening here by simply adding a clang-format configuration with a pre-commit hook. I really hope this project will grow and others would like to participate, and making sure the code is accessible & attractive to others is a huge deal.

Naming conventions

It was a very long and hard process. I tried at least 3 different styles but then decided to go with (almost) the same convention as the standard library.

Pros:

  • Familiar and feels native for most C++ developers
  • Used by many other widely-used libraries, including: boost, fmt & spdlog
  • Conveys the fact it’s a library, as most applications use different styles (Yes, I get the irony in that, but still…)

#linux #github #cpp #parser #code

Parsing the Linux procfs