CINXE.COM

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>LKML: Michael Frank: Re: RFC: Starting a stable kernel series off the 2.6 kernel</title><link href="/css/message.css" rel="stylesheet" type="text/css" /><link href="/css/wrap.css" rel="alternate stylesheet" type="text/css" title="wrap" /><link href="/css/nowrap.css" rel="stylesheet" type="text/css" title="nowrap" /><link href="/favicon.ico" rel="shortcut icon" /><script src="/js/simple-calendar.js" type="text/javascript"></script><script src="/js/styleswitcher.js" type="text/javascript"></script><link rel="alternate" type="application/rss+xml" title="lkml.org : last 100 messages" href="/rss.php" /><link rel="alternate" type="application/rss+xml" title="lkml.org : last messages by Michael Frank" href="/groupie.php?aid=10283" /><script> var _paq = window._paq = window._paq || []; /* tracker methods like "setCustomDimension" should be called before "trackPageView" */ _paq.push(["setDoNotTrack", true]); _paq.push(["disableCookies"]); _paq.push(['trackPageView']); _paq.push(['enableLinkTracking']); (function() { var u="//m.lkml.org/"; _paq.push(['setTrackerUrl', u+'matomo.php']); _paq.push(['setSiteId', '1']); var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0]; g.async=true; g.src=u+'matomo.js'; s.parentNode.insertBefore(g,s); })(); </script></head><body onload="es.jasper.simpleCalendar.init();" itemscope="itemscope" itemtype="http://schema.org/BlogPosting"><table border="0" cellpadding="0" cellspacing="0"><tr><td width="180" align="center"><a href="/"><img style="border:0;width:135px;height:32px" src="/images/toprowlk.gif" alt="lkml.org" /></a></td><td width="32">聽</td><td class="nb"><div><a class="nb" href="/lkml"> [lkml]</a> 聽 <a class="nb" href="/lkml/2005"> [2005]</a> 聽 <a class="nb" href="/lkml/2005/12"> [Dec]</a> 聽 <a class="nb" href="/lkml/2005/12/5"> [5]</a> 聽 <a class="nb" href="/lkml/last100"> [last100]</a> 聽 <a href="/rss.php"><img src="/images/rss-or.gif" border="0" alt="RSS Feed" /></a></div><div>Views: <a href="#" class="nowrap" onclick="setActiveStyleSheet('wrap');return false;">[wrap]</a><a href="#" class="wrap" onclick="setActiveStyleSheet('nowrap');return false;">[no wrap]</a> 聽 <a class="nb" href="/lkml/mheaders/2005/12/5/84" onclick="this.href='/lkml/headers'+'/2005/12/5/84';">[headers]</a>聽 <a href="/lkml/bounce/2005/12/5/84">[forward]</a>聽 </div></td><td width="32">聽</td></tr><tr><td valign="top"><div class="es-jasper-simpleCalendar" baseurl="/lkml/"></div><div class="threadlist">Messages in this thread</div><ul class="threadlist"><li class="root"><a href="/lkml/2005/12/3/55">First message in thread</a></li><li><a href="/lkml/2005/12/3/63">Adrian Bunk</a><ul><li><a href="/lkml/2005/12/3/65">Arjan van de Ven</a><ul><li><a href="/lkml/2005/12/4/37">Denis Vlasenko</a></li><li class="origin"><a href="/lkml/2005/12/5/368">Michael Frank</a><ul><li><a href="/lkml/2005/12/5/368">Horst von Brand</a><ul><li><a href="/lkml/2005/12/6/208">Michael Frank</a></li></ul></li></ul></li></ul></li><li><a href="/lkml/2005/12/3/80">Matthias Andree</a><ul><li><a href="/lkml/2005/12/3/81">Otavio Salvador</a></li><li><a href="/lkml/2005/12/3/84">David Ranson</a><ul><li><a href="/lkml/2005/12/3/88">Steven Rostedt</a><ul><li><a href="/lkml/2005/12/3/89">David Ranson</a></li></ul></li></ul></li><li><a href="/lkml/2005/12/3/91">Arjan van de Ven</a><ul><li><a href="/lkml/2005/12/3/94">"M."</a></li><li><a href="/lkml/2005/12/3/167">Matthias Andree</a><ul><li><a href="/lkml/2005/12/3/173">Greg KH</a></li><li><a href="/lkml/2005/12/3/193">"Jeff V. Merkey"</a></li></ul></li></ul></li></ul></li><li><a href="/lkml/2005/12/3/111">Jeff Garzik</a><ul><li><a href="/lkml/2005/12/3/127">Greg KH</a><ul><li><a href="/lkml/2005/12/3/197">Dmitry Torokhov</a><ul><li><a href="/lkml/2005/12/4/134">Greg KH</a></li></ul></li></ul></li><li><a href="/lkml/2005/12/3/157">Matthias Andree</a></li><li><a href="/lkml/2005/12/4/71">Michael Frank</a></li></ul></li><li><a href="/lkml/2005/12/5/108">Rob Landley</a></li><li><a href="/lkml/2005/12/10/95">Ryan Anderson</a></li></ul></li></ul></td><td width="32" rowspan="2" class="c" valign="top"><img src="/images/icornerl.gif" width="32" height="32" alt="/" /></td><td class="c" rowspan="2" valign="top" style="padding-top: 1em"><table><tr><td><table><tr><td class="lp">From</td><td class="rp" itemprop="author">Michael Frank <></td></tr><tr><td class="lp">Subject</td><td class="rp" itemprop="name">Re: RFC: Starting a stable kernel series off the 2.6 kernel</td></tr><tr><td class="lp">Date</td><td class="rp" itemprop="datePublished">Mon, 5 Dec 2005 10:47:24 +0100</td></tr></table></td><td></td></tr></table><pre itemprop="articleBody">On Saturday 03 December 2005 16:39, Arjan van de Ven wrote: > > > this is a contradiction. You can't eat a cake and > > > have it; either you're really low churn (like > > > existing -stable) or you start adding new features > > > like hardware support. the problem with hardware > > > support is that it's not just a tiny driver update. > > > If involves midlayer updates as well usually, and > > > especially if those midlayers diverge between your > > > stable and mainline, the "backports" are getting > > > increasingly unsafe and hard. > > > > In the beginning, backporting hardware support is > > relatively easy, and therefore cherry-picking from > > mainline 2.6 should be relatively safe. > > and then there's reality. At least in my experience as > distro kernel maintainer... you can do this for a few > months, but it gets exponentially more expensive after 4 > to 5 months. And "safe" is just not true. API, midlayer > and locking changes in the newer kernels just void that > concept entirely. And then there's the testing dillema; > the people who'd run such a branch are EXACTLY the ones > who wouldn't test prereleases of such branch (and yes 2.4 > suffers from this as well). > > I doubt many distros would go for it as well for longer > than a few months, simply because the hardware support > and other features are going to be needed for them. > > > Things will change as time passes by, but then there's > > the possibility to open the next branch and bring the > > older branch into a security-fixes only mode. > > if you end up with 5 such branches it's no longer fun, > trust me on that. Especially if the security fix is in a > tricky area or a high flux area, then it's just not a > matter of a simple backport anymore, even knowing if > you're vulnerable or not is going to be a pain. And then > there are the holes that happened to have gone away by > later changes... what are you going to do then... put > those changes in? that won't work longer term. > > > > If the current model doesn't work as you claim it > > > doesn't, then maybe the model needs finetuning. Right > > > now the biggest pain is the userland ABI changes that > > > need new packages; sometimes (often) for no real hard > > > reason. Maybe we should just stop doing those bits, > > > they're not in any fundamental way blocking general > > > progress (sure there's some code bloat due to it, but > > > I guess we'll just have to live with that). > > > > IOW, we should e.g. ensure that today's udev will still > > work flawlessly with kernel 2.6.30 (sic)? > > I'd say yes. It doesn't need to support all new > functionality, but at least what it does today it should > be able to do then. If that really isn't possible maybe > udev should be part of the kernel build and per kernel > version. Most problems are avoided when packages closely linked to the kernel like udev and pcmcia will be updated by the distro together with the kernel by way of package version dependencies matching for example 2.6.14 to udev 065-069 and kernel 2.6.15 to udev 070. udev 070 and later could block kernels <=2.6.14. udev bit me recently when a scanner stopped working after updating to udev 070. In that way I had a chance to figure out how udev works and how to make some rules. Neat! ;) Perhaps extra care should be taken by the distro to not break the 50-udev.rules configuration file. > > > This could work, but it should be officially announced > > that e.g. a userspace running kernel 2.6.15 must work > > flawlessly with _any_ future 2.6 kernel. > > I would argue that this in theory already is the current > policy. Now "any" is pretty wide, but still. Maybe any > such changes need to be scheduled to specific kernel > releases only. Eg only do it every 4th or 5th kernel > release. My 2 cents: Test drive some rc's (2.6.15-rc) Use current -stable kernel as much as possible (2.6.14.3) Critical apps use -stable -1 or -2 (2.6.13.x or 2.6.12.x) Using -stable to -stable -2 one is about 3 months behind the latest and greatest instability ;). As to security, most vulnerabilities are hard to exploit remotely and practical security can be much more improved by hiding detailed software versions from clients. Apache 2 on linux 2.6 will do instead of providing full vendor specific package versions! As to drivers, in case 3 month driver delay matters, HW vendor can improve situation substantially by not waiting 6+ months before (if at all) releasing drivers/docs for linux! Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at <a href="http://vger.kernel.org/majordomo-info.html">http://vger.kernel.org/majordomo-info.html</a> Please read the FAQ at <a href="http://www.tux.org/lkml/">http://www.tux.org/lkml/</a> </pre></td><td width="32" rowspan="2" class="c" valign="top"><img src="/images/icornerr.gif" width="32" height="32" alt="\" /></td></tr><tr><td align="right" valign="bottom"> 聽 </td></tr><tr><td align="right" valign="bottom">聽</td><td class="c" valign="bottom" style="padding-bottom: 0px"><img src="/images/bcornerl.gif" width="32" height="32" alt="\" /></td><td class="c">聽</td><td class="c" valign="bottom" style="padding-bottom: 0px"><img src="/images/bcornerr.gif" width="32" height="32" alt="/" /></td></tr><tr><td align="right" valign="top" colspan="2"> 聽 </td><td class="lm">Last update: 2005-12-05 15:31 聽聽 [from the cache] 漏2003-2020 <a href="http://blog.jasper.es/">Jasper Spaans</a>|hosted at <a href="https://www.digitalocean.com/?refcode=9a8e99d24cf9">Digital Ocean</a> and my Meterkast|<a href="http://blog.jasper.es/categories.html#lkml-ref">Read the blog</a></td><td>聽</td></tr></table><script language="javascript" src="/js/styleswitcher.js" type="text/javascript"></script></body></html>