zabbo

I, like countless others, use vim’s quickfix mode to ease the pain of the compile-fix-compile cycle. vim parses the output of the build so that it can present a summary of errors and enable navigation between them.

sparse is a tool that knows how to find errors in C code that compilers like gcc don’t notice. It requires minimal annotation in the source but provides invaluable functionality, like warning when endian conversions are forgotten.

Which brings us to the point of this post. sparse spits out multi-line errors messages that vim doesn’t completely understand:

tests/btree-stress.c:121:55: warning: incorrect type in initializer (different base types)
tests/btree-stress.c:121:55: expected restricted unsigned long long [usertype] b_offset
tests/btree-stress.c:121:55: got long long [signed] [usertype] offset

vim doesn’t know that each of these error messages belong to the same error. It offers them to the user as three separate errors:

:clist
35 tests/btree-stress.c:121 col 55: warning: incorrect type in initializer (different base types)
36 tests/btree-stress.c:121 col 55: expected restricted unsigned long long [usertype] b_offset
37 tests/btree-stress.c:121 col 55: got long long [signed] [usertype] offset

This is irritating because to navigate past this error you have to know to navigate past the next three errors. This has been an irritating me for, I don’t know, years now. I finally sat down and spent an hour or so poisoning my brain with vim’s arcane configuration.

set efm^=%W%f:%l:%c:\ warning:\ %m,%C%f:%l:%c:\ \ \ \ %m,%Z%f:%l:%c:\ \ \ \ %m

et voila. Now vim considers those three error messages as coming from one error:

:clist
35 tests/btree-stress.c:121 col 55 warning: incorrect type in initializer (different base types) expected restricted unsigned long long [usertype] b_offset got long long [signed] [usertype] offset

I’m sure that format won’t catch all of sparse’s errors but it’ll easy to derive additional formats from it.

I’m also sure that I’m not the first to do this. It would be nice if the sparse guys shipped a sourcable .vimrc along with the tools.

Andrew Morton’s talk at FOSDEM is available in ogg format. It’s worth a watch if you’re interested in Linux kernel development. He walks through technology that is currently consuming kernel developers. He starts with an interesting explicit link between the life cycles of products which include the kernel and the willingness of companies producing those products to fund development of the mainline kernel. He ends with the refreshing admission that the kernel development community exists to serve users.

I will admit that I was referred to this video because of his description of ext4: “the next horrible version of a horrible file system.” It’s hard for me to disagree, given this modern age of ZFS.

I was playing his video along in the background while working on an O_DIRECT bug when my ears perked up at his mention of AIO. I was pleased to hear him give a very reasonable overview of the awkward fibrils prototype I sent out which lead to Ingo’s more refined syslets. I’ll even go so far as to transcribe that part of his presentation:

AIO has been a problem for a long time. Even though we have all the AIO interfaces there, they don’t actually work. They’re only actually asynchronous for direct IO. So if you’re doing a normal buffered read or write to disk via AIO, all the interfaces work, but in fact we do the IO synchronously. There are patches out there to make the buffered IO asynchronous, but I’ve been the obstacle to merging those for the past couple of years.

And amazingly, Zach Brown at Oracle and Ingo Molnar have come up with a completely different way of doing it which has made me look very smart for not merging that code. What they’re proposing is, basically, make any system call asynchronous. So, potentially, the whole range of system calls in the kernel… you could fire them off and return to your application and later on get a notification when the system call completes. That, then, just means that all the AIO support we currently have we’ll no longer need ’cause you can just use normal old read and write and you just say “Yup, I want to do this in the background, please”.

Indeed, particularly that last bit.