![]() | |||||||||||||
Messages in this thread |
On Wed, 2008-07-23 at 11:04 -0400, Frank Ch. Eigler wrote: > Hi - > > I wrote: > > > > [...] One significant requirement for us is to keep working with > > > older kernels. [...] > > Maybe it's worth elaborating on why the need for backward > compatibility is different for systemtap than for typical kernel-side > code. > > The bulk of systemtap is a user-space program, and it does very > user-spacey things like parsing dwarf and invoking compilers, running > network servers. Soon it will include user-space libraries. It is so > different from the stuff normally found there that no one has AFAIK > seriously proposed that the entire software be made part of the kernel > git tree. So it is an ordinary separate user-space package, built by > users and distributors. > > 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. > > 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. We > cannot easily take old support away, because then the same user-space > code base would no longer run against actually installed kernels. > > To draw an analogy, systemtap is somewhat like low-level userspace > code like glibc or syslogd or udevd. I hope no one would seriously > propose casually committing code to those packages that would make > them unusable on prior kernel versions. Accepting such a patch would > require their maintainers to fork outright every time a kernel change > occurs. > > Things are good however if the low-level userspace changes are > backward-compatible, so that the new kernel facility is used when > present, but the software does not regress if it is not. I believe > this is what we need to aim for, even though it puts the bulk of the > burden on systemtap (or glibc, or ...). > > I hope this fills in some of the gaps in the background. Why does a new version of stap have to work on ancient kernels? A new gnome version requires a new gtk version, a new kde version requires a new qt etc.. so why does a new stap not require a new kernel? Why isn't only supporting the last few kernels, say for example as far back as there are -stable series at the moment of release, good enough? People who insist on running stale kernels are usually the same people who run stale userspace - we call those enterprise people - so why can't they run matching stale version of the kernel and stap? | ||||||||||||
| Last update: 2008-07-23 17:35 [W:0.285 / U:0.010 seconds] ©2003-2008 Jasper Spaans | |||||||||||||