![]() | |||||||||||||
Messages in this thread |
Arjan van de Ven <arjan@infradead.org> writes: > [...] >> It does happen to *generate* kernel modules. The way that such a >> module must interface with any particular kernel is naturally subject >> to the whims & desires of the kernel du jour. This is why we have a >> mass of mechanism to try to automatically speak to each kernel version >> as appropriate. > and this is where I strongly disagree. THIS part *has* to be in the > kernel source, so that we can change it WITH the kernel as we change > it. [...] But to have any chance at all of systemtap being > sustainable, this part of the stack has to be together with where > the changes happen. OK. It will take us some time to figure out to what extent this would be feasible. Maybe a topic for Portland. >> It is desirable to minimize this mass for obvious reasons. When a new >> upstream kernel comes out with a tasty new feature -- or a less tasty >> API rewrite -- we need to extend systemtap to support that too. > > At that point you are already 3 months too late for me, and probably > for most of my fellow kernel hackers. (Really? Have we ever been 3 months behind supporting the git kernel?) > (and when it's seen it gets a rather luke warm reception, but that's > a different story). I hope the backward compatibility issue, as it stands today, helps explain the reasons for the current deal with kprobes. In the interim (before we come up with a way of moving more kernel-coupled systemtap code into kernel.org/git), would y'all consider an arrangement? Those of you who care about systemtap, and are intending to make an incompatible kernel/module interface change, please run the systemtap testsuite before & after. If it regresses, send us a note or a patch. If practical, we'll integrate it (and add any backward-compatibility hacks if needed) into systemtap. - FChE | ||||||||||||
| Last update: 2008-07-23 18:45 [W:0.755 / U:0.040 seconds] ©2003-2008 Jasper Spaans | |||||||||||||