Archive

Posts Tagged ‘debugfs’

Two things I hate about debugfs

August 29, 2010 Leave a comment

I am a major fan of the Linux kernel’s debugfs filesystem. For those not familiar with its awesome power, read these LWN articles from 2004 and 2009, and the Wikipedia entry.

I’ve written IOCTLs in the past, and always felt like the sterotypical monolithic switch statement was a bit lame – so once I ran across debugfs, I kicked ioctls to the curb and never looked back. There’s something so completely elegant and awesome about a simple

$ cat /sys/kernel/debug/mymod/var1; echo 'erase' > /sys/kernel/debug/mymod/buffer2

But as I get more and more into debugfs, two things keep irritating me and hence this post.

Gripe #1: EXPORT_SYMBOL_GPL

Why in the world is debugfs exported as GPL only? Do the kernel developers really think that people who write proprietary modules don’t need debugfs? Or do they really want people abusing /sys or /proc files even further, leading to more mess and chaos?

Or, is it yet another manefestation of Linux’s split personality disorder reaction to non-GPL code? After all, the core kernel developers still can’t decide if non-GPL kernel modules are a violation of the GPL… so I shouldn’t be surprised to see something as awesome and inspiring as debugfs locked down to GPL exports.

But I am surprised, and it does grate on me. I love debugfs but hate that it’s exported GPL only.

Gripe #2: boilerplate code

Now this one is a bit more subjective, and quite possibly a sign that I’m doing something wrong… but I find myself writing a lot of boilerplate code. Sure, debugfs makes it super trivial to read/write simple variables —

struct dentry my_foo = debugfs_create_x32(name, perms, root, u32_ptr);

But creating a more complex file with custom logic requires a struct file_operations which looks quite boilerplate:

static struct file_operations file1_ops = {
    .open = file1_open,
    .release = file1_release,
    .read = file1_read,
    .write = file1_write
};

That’s not so bad when you’re creating one debugfs file, but try creating 5 or 10 or 20. After a while, all the structs look ver very similar, and all the functions look the same too. Open sets the file pointer’s private data to the inode’s private data, possibly allocates some RAM. Read does a simple_read_from_buffer. Write kmalloc’s, copies from users, then does a strncmp to see if the user echo’d the right magic token to kick off some logic. Close undoes whatever open did.

So while I love the flexibility and power of debugfs, the boilerplate code lends to many copy/paste errors and leaves me wishing debugfs would handle more for me in the normal boring cases. Or at least add some new file types… debugfs_create_text_buffer() anyone?

In Summary

In summary, I love debugfs. I’m a die hard Linux command line freak and debugfs fits me like a glove. But my experience with debugfs hasn’t been completely Utopian and there’s a couple of annoyances that leave me wanting a little more polish.

Hmmm…. wait… it’s open source right?

Maybe I’ll chip in some code, so I’m not just the whiny poser throwing stones from the corner.

Best

Atto

Categories: Uncategorized Tags: , ,