LWN: Comments on "Tools for porting drivers"

Tools for porting drivers

nix — Thu, 30 Nov 2017 13:02:22 +0000

It does look really expensive: it does git shows of everything in history (arbitrarily restricted to v3.0..v4.6), and of all lines adding anything, and of all lines removing anything... and has Julia's homedir wired into it as well as the path to the Linux dir and the v3.0..v4.6 restriction... oh and most of the code to generate the indexes is commented out.

This bit of the system looks like something that has never really been meant for others' use :)

(hm, if linux_idutils_U0.index is no longer useful, as suggested by the commit comment in 268c28a1a27c0fe160877ac74381d41cfb8a4645, why is it still in the git repo, given that it's one of the largest indexes? Why does the code still reference it? Oh and why does the next commit touching the indexer (cb0ea76886dbb450dd401ffb59430103c0b496eb) not only add a word index but also comment out the code to generate all the other indexes, even though the code still references those too? I get the impression that this is *really* not meant for others' use, which is a shame because I wanted to run it on Linux > 4.6 but it's hard to figure out even which indexes are needed, let alone how to regenerate them.)

Tools for porting drivers

ThinkRob — Thu, 30 Nov 2017 07:54:55 +0000

To add on to this (as I think about it more) there probably is a cut-off point where AoT would have been a win, but it is at this point that LKML twinges and hops over to this discussion to point why heuristics are bad and rarely the answer, etc.

And you know, in this case, I would tend to agree with them. I'd rather burn a predictable amount of CPU and disk IO than have opaque "no more CPU/disk" cliffs to fall off of. AoT is still an option though, and hey you could add it to the rpm/deb setup packages for the kernel source (with a nice README for the tool for people writing against mainline.) Not perfect, but possibly more efficient than just spinning every time you invoke.

Then again, this is way the hell out of my wheelhouse, so I could be dead wrong. :D

Tools for porting drivers

ThinkRob — Thu, 30 Nov 2017 07:51:32 +0000

> (Why can't these be generated on the fly? *Can* they, so this can be used for projects other than the Linux kernel? the fact that the generator has Julia's homedir hardwired into it is not especially reassuring.)

My guess -- with no benchmarking whatsoever to support it -- is that the cost of indexing each time is such that it breaks (or at least seriously impedes) the workflow where you start with $(portion of foo) and gradually refine to $foo. That's a lot of wasted work that gets done each time, and for that use case it's easier to simply generate AoT than burn CPU each time the search is fired. Ideally the user would get a choice, which is always a good way to cut off the "my workflow!" argument at the knees... but I can understand if they don't want to roll that out on day 0. It is an increase in complexity, after all. [insert usual lecture on complexity, bugs, etc. here]

Besides, this being FOSS. I give it two, three days until someone's got a patchset to do just that. ;-)

Tools for porting drivers

nix — Wed, 29 Nov 2017 16:47:25 +0000

I think Prequel is perhaps the most useful-looking grep replacement for large codebases and lots of history that I've ever seen.

Needs an Emacs mode! (I might write one once I've used it enough to figure out what it should do!)

Now to read the paper and figure out why it needs massive idutils indexes in the source tree. (Why can't these be generated on the fly? *Can* they, so this can be used for projects other than the Linux kernel? the fact that the generator has Julia's homedir hardwired into it is not especially reassuring.)

Tools for porting drivers

higuita — Wed, 29 Nov 2017 00:08:30 +0000

This project really needs to be advertised more, for something released in 2007, it's the first time i read about it and i suspect that most device makers also do not know it

Tools for porting drivers

farnz — Tue, 28 Nov 2017 11:55:37 +0000

How does this interact with the "Backports Project"? IIUC, the Backports Project provides compatibility shims so that you can take your driver from latest Linus release and have it build and run on older kernels (currently as far back as 3.0); the idea is that it rewards companies who work against current mainline with a cheap backport to whatever kernel version their customers use.

Is this only the flipside of that project in that it makes forward porting easier, so that you can start with a vendor driver for a randomly chosen kernel and bring it forward ready to put into mainline, or is there more to it?

Tools for porting drivers

unixbhaskar — Tue, 28 Nov 2017 05:41:58 +0000

Cool ! thanks, Julia.