Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Philippe Gerum wrote: On Fri, 2006-12-01 at 23:46 +0100, Philippe Gerum wrote: On Thu, 2006-11-30 at 14:19 +0100, Jan Kiszka wrote: Anyway, there is an unreleased work-in-progress patch for x86 over -rc6 by Philippe. I recently had the chance to test it and hack a bit on the SMP IO-APIC part. It seems to work fine under UP, but SMP had some issues that are identified, but still need to be addressed - thanks to genirq, now in a widely arch-independent way. Philippe, I know you are very busy, but shouldn't we make a pre-release available already, also to discuss further how to deal best with genirq on other platforms beyond x86? Actually, the draft patch I sent you did not boot on my SMP box today, so qemu seems to have been a bit too friendly. Knowing that, issuing a half-baked patch would have made no sense, so I finally refrained from doing that. Since I'm now basically in love with the genirq layer (at least for x86) compared to the utter mess that we had to endure previously, I've decided to tackle the issue completely, and rewrite the I-pipe interrupt flow in order to leverage it. Will post something asap. Ok, here we are. I've just merged 2.6.19-ipipe-1.6-00. It has been tested on a low-end classic Pentium 90Mhz, a dusty two-way Celeron 750Mhz, and on a terrible Celeron 1GHz oldish laptop. Looks ok so far, and even passed the horrid dohell test on the SMP box, just smiling. However, I don't have the required hw at hand to check if our friend the MSI support is not killing us once more. This said, the MSI support in 2.6.19 also conforms to the genirq specs, so there's hope. The patch is available from the Adeos download area, and I've also committed it to the SVN trunk/. Feedback welcome, PS: I have the corresponding quilt-managed patches available upon request, to the people who want to use this work as a reference for porting to other archs. You mean that you have separate patches for the common and arch dependent part. That would be nice. I'm interested! As a consequence we could provide separated patches in general and prepare-kernel.sh applies them in sequence. Just an idea for the future. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
On Sat, 2006-12-02 at 10:36 +0100, Wolfgang Grandegger wrote: Philippe Gerum wrote: On Fri, 2006-12-01 at 23:46 +0100, Philippe Gerum wrote: On Thu, 2006-11-30 at 14:19 +0100, Jan Kiszka wrote: Anyway, there is an unreleased work-in-progress patch for x86 over -rc6 by Philippe. I recently had the chance to test it and hack a bit on the SMP IO-APIC part. It seems to work fine under UP, but SMP had some issues that are identified, but still need to be addressed - thanks to genirq, now in a widely arch-independent way. Philippe, I know you are very busy, but shouldn't we make a pre-release available already, also to discuss further how to deal best with genirq on other platforms beyond x86? Actually, the draft patch I sent you did not boot on my SMP box today, so qemu seems to have been a bit too friendly. Knowing that, issuing a half-baked patch would have made no sense, so I finally refrained from doing that. Since I'm now basically in love with the genirq layer (at least for x86) compared to the utter mess that we had to endure previously, I've decided to tackle the issue completely, and rewrite the I-pipe interrupt flow in order to leverage it. Will post something asap. Ok, here we are. I've just merged 2.6.19-ipipe-1.6-00. It has been tested on a low-end classic Pentium 90Mhz, a dusty two-way Celeron 750Mhz, and on a terrible Celeron 1GHz oldish laptop. Looks ok so far, and even passed the horrid dohell test on the SMP box, just smiling. However, I don't have the required hw at hand to check if our friend the MSI support is not killing us once more. This said, the MSI support in 2.6.19 also conforms to the genirq specs, so there's hope. The patch is available from the Adeos download area, and I've also committed it to the SVN trunk/. Feedback welcome, PS: I have the corresponding quilt-managed patches available upon request, to the people who want to use this work as a reference for porting to other archs. You mean that you have separate patches for the common and arch dependent part. Mostly, yes. The patches are split by function, but this usually correlates with the noarch / arch-specific break down view too. That would be nice. I'm interested! http://download.gna.org/adeos/patches/v2.6/i386/split/ As a consequence we could provide separated patches in general and prepare-kernel.sh applies them in sequence. Just an idea for the future. Problem is that we would have to store a set of patches for each Adeos version/arch combo, instead of a single one. What advantage do you see in breaking the Adeos patches down for prepare-kernel.sh? Wolfgang. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Philippe Gerum wrote: On Sat, 2006-12-02 at 10:36 +0100, Wolfgang Grandegger wrote: Philippe Gerum wrote: On Fri, 2006-12-01 at 23:46 +0100, Philippe Gerum wrote: On Thu, 2006-11-30 at 14:19 +0100, Jan Kiszka wrote: Anyway, there is an unreleased work-in-progress patch for x86 over -rc6 by Philippe. I recently had the chance to test it and hack a bit on the SMP IO-APIC part. It seems to work fine under UP, but SMP had some issues that are identified, but still need to be addressed - thanks to genirq, now in a widely arch-independent way. Philippe, I know you are very busy, but shouldn't we make a pre-release available already, also to discuss further how to deal best with genirq on other platforms beyond x86? Actually, the draft patch I sent you did not boot on my SMP box today, so qemu seems to have been a bit too friendly. Knowing that, issuing a half-baked patch would have made no sense, so I finally refrained from doing that. Since I'm now basically in love with the genirq layer (at least for x86) compared to the utter mess that we had to endure previously, I've decided to tackle the issue completely, and rewrite the I-pipe interrupt flow in order to leverage it. Will post something asap. Ok, here we are. I've just merged 2.6.19-ipipe-1.6-00. It has been tested on a low-end classic Pentium 90Mhz, a dusty two-way Celeron 750Mhz, and on a terrible Celeron 1GHz oldish laptop. Looks ok so far, and even passed the horrid dohell test on the SMP box, just smiling. However, I don't have the required hw at hand to check if our friend the MSI support is not killing us once more. This said, the MSI support in 2.6.19 also conforms to the genirq specs, so there's hope. The patch is available from the Adeos download area, and I've also committed it to the SVN trunk/. Feedback welcome, PS: I have the corresponding quilt-managed patches available upon request, to the people who want to use this work as a reference for porting to other archs. You mean that you have separate patches for the common and arch dependent part. Mostly, yes. The patches are split by function, but this usually correlates with the noarch / arch-specific break down view too. That would be nice. I'm interested! http://download.gna.org/adeos/patches/v2.6/i386/split/ As a consequence we could provide separated patches in general and prepare-kernel.sh applies them in sequence. Just an idea for the future. Problem is that we would have to store a set of patches for each Adeos version/arch combo, instead of a single one. What advantage do you see in breaking the Adeos patches down for prepare-kernel.sh? Maintenance issues for the noarch part, e.g., if you fix a bug in the common part or add new features it's available for all arch. But I see your point. It's a bit more complicated and there are also patch version numbers. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
On Sat, 2006-12-02 at 18:37 +0100, Wolfgang Grandegger wrote: Philippe Gerum wrote: On Sat, 2006-12-02 at 10:36 +0100, Wolfgang Grandegger wrote: Philippe Gerum wrote: On Fri, 2006-12-01 at 23:46 +0100, Philippe Gerum wrote: On Thu, 2006-11-30 at 14:19 +0100, Jan Kiszka wrote: Anyway, there is an unreleased work-in-progress patch for x86 over -rc6 by Philippe. I recently had the chance to test it and hack a bit on the SMP IO-APIC part. It seems to work fine under UP, but SMP had some issues that are identified, but still need to be addressed - thanks to genirq, now in a widely arch-independent way. Philippe, I know you are very busy, but shouldn't we make a pre-release available already, also to discuss further how to deal best with genirq on other platforms beyond x86? Actually, the draft patch I sent you did not boot on my SMP box today, so qemu seems to have been a bit too friendly. Knowing that, issuing a half-baked patch would have made no sense, so I finally refrained from doing that. Since I'm now basically in love with the genirq layer (at least for x86) compared to the utter mess that we had to endure previously, I've decided to tackle the issue completely, and rewrite the I-pipe interrupt flow in order to leverage it. Will post something asap. Ok, here we are. I've just merged 2.6.19-ipipe-1.6-00. It has been tested on a low-end classic Pentium 90Mhz, a dusty two-way Celeron 750Mhz, and on a terrible Celeron 1GHz oldish laptop. Looks ok so far, and even passed the horrid dohell test on the SMP box, just smiling. However, I don't have the required hw at hand to check if our friend the MSI support is not killing us once more. This said, the MSI support in 2.6.19 also conforms to the genirq specs, so there's hope. The patch is available from the Adeos download area, and I've also committed it to the SVN trunk/. Feedback welcome, PS: I have the corresponding quilt-managed patches available upon request, to the people who want to use this work as a reference for porting to other archs. You mean that you have separate patches for the common and arch dependent part. Mostly, yes. The patches are split by function, but this usually correlates with the noarch / arch-specific break down view too. That would be nice. I'm interested! http://download.gna.org/adeos/patches/v2.6/i386/split/ As a consequence we could provide separated patches in general and prepare-kernel.sh applies them in sequence. Just an idea for the future. Problem is that we would have to store a set of patches for each Adeos version/arch combo, instead of a single one. What advantage do you see in breaking the Adeos patches down for prepare-kernel.sh? Maintenance issues for the noarch part, e.g., if you fix a bug in the common part or add new features it's available for all arch. I think this should be easier once we have moved to git, pulling commits is made simple (yeah, I'm late on this too...) But I see your point. It's a bit more complicated and there are also patch version numbers. Wolfgang. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
Philippe Gerum wrote: On Sat, 2006-12-02 at 18:37 +0100, Wolfgang Grandegger wrote: Philippe Gerum wrote: On Sat, 2006-12-02 at 10:36 +0100, Wolfgang Grandegger wrote: Philippe Gerum wrote: On Fri, 2006-12-01 at 23:46 +0100, Philippe Gerum wrote: On Thu, 2006-11-30 at 14:19 +0100, Jan Kiszka wrote: Anyway, there is an unreleased work-in-progress patch for x86 over -rc6 by Philippe. I recently had the chance to test it and hack a bit on the SMP IO-APIC part. It seems to work fine under UP, but SMP had some issues that are identified, but still need to be addressed - thanks to genirq, now in a widely arch-independent way. Philippe, I know you are very busy, but shouldn't we make a pre-release available already, also to discuss further how to deal best with genirq on other platforms beyond x86? Actually, the draft patch I sent you did not boot on my SMP box today, so qemu seems to have been a bit too friendly. Knowing that, issuing a half-baked patch would have made no sense, so I finally refrained from doing that. Since I'm now basically in love with the genirq layer (at least for x86) compared to the utter mess that we had to endure previously, I've decided to tackle the issue completely, and rewrite the I-pipe interrupt flow in order to leverage it. Will post something asap. Ok, here we are. I've just merged 2.6.19-ipipe-1.6-00. It has been tested on a low-end classic Pentium 90Mhz, a dusty two-way Celeron 750Mhz, and on a terrible Celeron 1GHz oldish laptop. Looks ok so far, and even passed the horrid dohell test on the SMP box, just smiling. However, I don't have the required hw at hand to check if our friend the MSI support is not killing us once more. This said, the MSI support in 2.6.19 also conforms to the genirq specs, so there's hope. The patch is available from the Adeos download area, and I've also committed it to the SVN trunk/. Feedback welcome, PS: I have the corresponding quilt-managed patches available upon request, to the people who want to use this work as a reference for porting to other archs. You mean that you have separate patches for the common and arch dependent part. Mostly, yes. The patches are split by function, but this usually correlates with the noarch / arch-specific break down view too. That would be nice. I'm interested! http://download.gna.org/adeos/patches/v2.6/i386/split/ As a consequence we could provide separated patches in general and prepare-kernel.sh applies them in sequence. Just an idea for the future. Problem is that we would have to store a set of patches for each Adeos version/arch combo, instead of a single one. What advantage do you see in breaking the Adeos patches down for prepare-kernel.sh? Maintenance issues for the noarch part, e.g., if you fix a bug in the common part or add new features it's available for all arch. I think this should be easier once we have moved to git, pulling commits is made simple (yeah, I'm late on this too...) Ah, I just read the keyword: git! ;) Rough idea from my side on a potential organisation of the git trees: o A generic I-pipe core tree that primarily targets git head (i.e. 2.6) o One branch for git head, pulls both from Linus' tree and the I-pipe core o One tree for each major 2.6 version in maintenance mode, pulls from related stable branch and I-pipe core (when applicable) o Only if required: a generic I-pipe core tree for 2.4 o One tree for 2.4 head to maintain x86 o One tree for 2.4 ELDK to maintain PPC Quite a lot trees... Do you this this may work? Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 1/3] decouple spinlock stats from XENO_OPT_STATS
Ok, I ended up finding such decoupling cleaner, given that we don't drag the full debug overhead when activating /proc/xenomai/locks in SMP mode, thanks to the reorganized debug options. Gilles, is this patch series ok for you too, and particularly the POSIX changes? -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] I-pipe git trees
On Sat, 2006-12-02 at 18:59 +0100, Jan Kiszka wrote: [...Resuming the discussion on both interested lists...] Rough idea from my side on a potential organisation of the git trees: o A generic I-pipe core tree that primarily targets git head (i.e. 2.6) o One branch for git head, pulls both from Linus' tree and the I-pipe core What would be the purpose of this branch? o One tree for each major 2.6 version in maintenance mode, pulls from related stable branch and I-pipe core (when applicable) o Only if required: a generic I-pipe core tree for 2.4 It should not be needed. I-pipe for 2.4 is in deep maintenance mode, and the latest 2.6 pipeline core is no more compatible with the 2.4 version anyway, due to several infrastructure changes in the vanilla kernel, e.g. genirq. So from now on, we won't backport much from the 2.6 series to 2.4, except perhaps critical bug fixes. Most (if not all) of the changes on those trees are much likely to be 2.4-specific, as time passes. o One tree for 2.4 head to maintain x86 o One tree for 2.4 ELDK to maintain PPC Yes, we definitely need those. Quite a lot trees... Do you this this may work? It really depends on what we try to achieve with implementing a new workflow. At least, I can tell why we need a new workflow, which could give us some hint about the one we should pick. Basically, the reason is that I don't scale anymore when it comes to maintain the six I-pipe ports, even if for a few of them, I'm not directly maintaining the arch-dependent parts (just reviewing), but only the generic core. Given that the Xenomai maintenance is now unfortunately done on my free time too, something needs to be done in order to optimize those processes. Now that some recurrent contributors showed up for helping with some ports, it's time to allow the various I-pipe ports to develop at their own pace, while still being reasonably in sync with a reference implementation. There are quite talented people out there who know better than me when it comes to hw platforms they are dealing with on a daily basis, so let them tackle the issue, if they accept to. The bottom-line: - Not all trees are going to be cloned from mainline; some architectures are not even mainline yet (e.g. blackfin). This is why relying on competent people for tracking the right kernel source for any given architecture is critical, and beyond that, people who know enough about the technical trends going on for the Linux port in question (e.g. ppc and arm). - In the new workflow, I'm going to keep working on the generic I-pipe core, and lead the maintenance for the ports which have no better maintainer in sight. - I want this process to add flexibility, by decoupling the evolution of the various ports, without introducing chaos. This should be possible with all the maintainers keeping an eye on the reference implementation I'll be working on, and improving with their input. - Keep it simple. I'm slow, damnit! -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
