HI folks, I dont think it matters much for the RT-PREEMPT kernels, since they are at 3.4+ at this moment I don't know if it's 3.5 or 3.6 that's the latest. But at the moment I don't think it matters, since it's using the POSIX API.
Atleast for debian, I used to compile the latest kernels to run on production machines, I see no or little added value from distro patches, RH is a bad example ... So I would say go with latest that the distro supports, and if considering something else I would consider the kernels marked for 'long time support' by Linus & Friends ... RTAI & Xenomai are more dependent on the version and thus can decide, as long as it's as new one as possible. 2012/10/11 EBo <e...@sandien.com>: > Michael, > > Quite right, and I am sorry for jumping in without noting that the last > time I poked around the kernel folks were focusing on the 3.2.14 for > integration (so it was not just me). At that time I had been bouncing > ideas back and forth with someone (Lars?) and that seemed to be the most > stable sources. I do believe that this is all based off of the vanilla > kernel sources. If I were not so busy at the moment I would dig through > my notes and see if I could outline the various groups we were tracking > for RT patches and make sure we were all talking about the same folks. > So, please accept my apologies for the knee jerk comment and not > detailing it a bit more thoroughly. > > EBo -- > > > On Thu, 11 Oct 2012 21:05:54 +0200, Michael Haberler wrote: >> Ebo, >> >> I would think this requirement is driven more from the availability >> and performance side of RT patches than from what certain distros do, >> and me must make a priority decision here between 'tracking a given >> distro' and 'having a recent kernel' - note we are just pulling our >> leg out of a version trap (although that came with a kernel version, >> not a distro) >> >> of course it would be nice if we found a matching kernel in some >> distro, and that doesnt exclude such matching kernels are built - I'm >> discussing with Seb how we can set up a buildbot scheme for kernels - >> (NB: plural) so if somebody comes around and supplies patches that >> should find its way there so such a matching kernel for say Xenomai >> is >> automatically built >> >> assuming Lars is right - which I dont doubt - then the RT_PREEMPT >> kernel will have to be pretty much bleeding edge and generic, like >> this: http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/ >> >> -- >> >> What I am completely unclear about, and what I would appreciate being >> educated about - what are the compatibility issues of running a >> non-distro kernel on say Ubuntu 10.04 or 12.04 - I do that all the >> time, and still have to fund a problem, so I'm a bit unsure what the >> actual value-add of distro-specific kernel patches is >> >> - Michael >> >> >> >> >> >> Am 11.10.2012 um 19:52 schrieb EBo: >> >>> On Thu, 11 Oct 2012 08:02:14 +0200, Michael Haberler wrote: >>>> ... >>>> >>>> from what I collected so far, Linux 3.2.21 seems the latest 3.x >>>> series supported by xenomai, which maps fine onto the Ubuntu >>>> LTS/kernel version list: >>>> http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html >>>> (precise LTS being the target platform) >>>> >>>> for RT_PREEMPT I'm open to suggestions - please share; by default >>>> I'd >>>> go for the same base version as the xenomai kernel >>>> >>>> ... >>> >>> my 2c would be to pick 3.2.14 for one of the kernel numbers as that >>> is >>> the newest version that has been integrated into a couple of >>> distributions. If Ubuntu has a different one they are throwing >>> resources into, then that might not be a bad choice after all. >>> >>> Just to throw it out there, we could look at a TinyCoreLinux >>> version. >>> That would run bootable off of a small USB drive, and can be >>> installed >>> on a machine. Jut thinking out loud... >>> >>> EBo -- >>> >>> >>> ------------------------------------------------------------------------------ >>> Don't let slow site performance ruin your business. Deploy New Relic >>> APM >>> Deploy New Relic app performance management and know exactly >>> what is happening inside your Ruby, Python, PHP, Java, and .NET app >>> Try New Relic at no cost today and get our sweet Data Nerd shirt >>> too! >>> http://p.sf.net/sfu/newrelic-dev2dev >>> _______________________________________________ >>> Emc-developers mailing list >>> Emc-developers@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/emc-developers >> >> >> >> ------------------------------------------------------------------------------ >> Don't let slow site performance ruin your business. Deploy New Relic >> APM >> Deploy New Relic app performance management and know exactly >> what is happening inside your Ruby, Python, PHP, Java, and .NET app >> Try New Relic at no cost today and get our sweet Data Nerd shirt too! >> http://p.sf.net/sfu/newrelic-dev2dev >> _______________________________________________ >> Emc-developers mailing list >> Emc-developers@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-developers > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
