El Dimecres, 15 de gener de 2014, a les 20:51:42, Gilles Chanteperdrix va escriure: > On 01/15/2014 05:15 PM, Leopold Palomo-Avellaneda wrote: > > Hi, > > > > first of all please CC to me because I'm not in the kernel list. I saw the > > message in the web interface. > > > >>> So, what about to create a linux-image package, with a kernel packaged > >>> with xenomai? > >> > >> All kernel featuresets should be temporary, with the project aiming to > >> get their changes merged upstream. > >> http://www.xenomai.org/index.php/Xenomai:Roadmap doesn't say anything > >> about doing that, and if that isn't planned then I will reject this > >> proposal. > > > > well, Gilles could answer better than me, but Xenomai works with the adeos > > patch and the linux kernel is just another task. I don't know if it could > > be mixed, they are two different things. One is an kernel with the > > scheduler modified to try to do realtime features and another is an > > subkernel on Linux kernel run as a task. > > That settles it then, it has been made very clear a long, long time ago that > the Adeos patch would never be merged into mainline. > > > Another thing is if they will converge with the PREEMP_RT patches from > > Ingo > > Molnar and Co. > > > >> We already provide realtime kernel images using the PREEMPT_RT patch > >> series. Two types of realtime kernel would be an extravagance. > > > > One is a "Soft" realtime and another "Hard" realtime. Although in my area > > (robotics), the 95% of the applications could be perfect with the > > PREEMPT_RT version, there's another areas that could be benefit this > > option, so IMHO it's not an extravagance. I can say more, if Debian could > > have a group of packages that work on a hard realtime subset, specially > > on ARM, it would be a good plus to the project; better, we are towards > > the "world domination" ;-) > > No, PREEMPT_RT is hard real-time as well, the two approaches are simply > different and both have their strengthes and weaknesses. You will find > a comparison between the various approaches for getting real-time > services with Linux here: > > http://www2.hs-augsburg.de/informatik/vorlesungen/echtzeit/script/system/lin > ux_rt01.html > > The Adeos/Xenomai approach corresponds more or less to section 6. Ohhh, thanks for the clarification. I was wrong. And the link you sent is incredible!!!! how long and clear message. This information should be on the xenomai wiki. > >> But as > >> Xenomai apparently runs on top of PREEMPT_RT now, that might not be a > >> problem. > > > > I don't think so. I don't apply the PREEMPT_RT patch to use Xenomai. > > Gilles, I'm right? > > The idea with the next (currently unreleased) branch of Xenomai is to > offer users the choice of the kernel they want to use. The aim of > Xenomai is not to provide real-time services using a particular > approach or another, but to help porting application from proprietary > RTOSes, such as vxworks, psos, etc... to a real-time Linux-based > system. The particular approach used to get real-time services is > secondary. So, I understand that the libxenomai would be compiled against one or another kernel patch, no? > >>> - it has patches for previous versions of the linux provided by debian. > >> > >> There is only one version of Linux in each suite, and this is not likely > >> to change. So if Xenomai doesn't keep up with upstream development then > >> it would have to be disabled at times. (We currently do this with the > >> 'rt' featureset on odd-numbered Linux versions.) > > > > Ok, Gilles, would be possible to be sync and have a Adeos patch for the > > stable version included in debian? > > AFAIK the version of Linux in debian stable is 3.2, and we already have > an Adeos patch for 3.2. Or are you talking about the Linux version > available for stable in debian backports? Well, we should work on the _next_ stable release. Looking the Ben Hutchings mail: > (Based on current release schedules, the current upstream version of > Linux at the time of jessie's freeze (5th November) will be 3.17 so I > would expect us to use either 3.16 or 3.17. Ideally this would also be > the base version for Greg K-H's next longterm branch. I have no > intention of maintaining two longterm branches myself.) so, the idea should be to have an Adeos patch based on the long term branch. For instance, currently we have in amd64 3.12+55, in unstable, testing and backports. > >> There needs to be a nominated maintainer for each featureset. (In > >> practice I've been looking after the 'rt' featureset, but I'm not > >> offering to do that for anything else.) The maintainer will need to be > >> ready to resolve patch (and semantic) conflicts whenever the Linux > >> upstream version is updated, including stable updates. > > > > Well, Roland have done a good job with the xenomai package, and AFAIK some > > xenomai upstream and debian user, and I can help for this of course. > > No question here that the one who would maintain the xenomai-patched > linux image would have to be familiar with xenomai. My sentence was bad written. AFAIK some xenomai upstream are debian user, no Gilles? Leopold -- -- Linux User 152692 PGP: 0xF944807E Catalonia ------------------------------------- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
Attachment:
signature.asc
Description: This is a digitally signed message part.