Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
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. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-help] Re: [Xenomai-core] [ANNOUNCE] Xenomai Example Repository
On Fri, 2006-12-01 at 23:47 +0100, Wolfgang Grandegger wrote: > > [...] > > > This said, I agree that adding a fake module directory to capture the > > flags set by the main kernel Makefile is one step beyond ugliness; the > > other approach being to only provide a 2.6 Makefile frag. As 2007 > > approaches, I think that anyone still involved with projects relying on > > 2.4 kernels do know how to build 2.4 modules for the targeted platform. > > I think the example modules should compile on any platform and the > "kernel CFLAGS capturing" trick is the most straight-forward way to do > it for 2.4. It simplifies our life, avoids fiddling with various arch > dependent flags in the Makefile, which will be even more ugly, and it > serves as an example on how to get proper flags. Therefore I tend to add > an appropriate script to the "scripts" subdirectory. That would be acceptable too; the capture trick is ugly, but if we really want to have the generic examples available to all platforms, I see no other way to get the exact compilation and link flags. So it's basically a matter of choice: either we don't provide any Makefile frag for 2.4, or we implement the capture trick so that every platform can compile them. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-help] Re: [Xenomai-core] [ANNOUNCE] Xenomai Example Repository
Philippe Gerum wrote: On Fri, 2006-12-01 at 18:22 +0100, Jan Kiszka wrote: Wolfgang Grandegger wrote: Jan Kiszka wrote: Hi, the new Xenomai example repository has been created. I don't want to repeat here what is explained already on the related wiki page, please have a look at http://www.xenomai.org/index.php/Examples Instead, let me sketch what could be done next: o Port existing examples, snippets, demos from ksrc/skins/* over, make them compilable and runnable if required. o Identify what kind of examples are lacking. You, the user, is needed here. What do *you* think is missing, what would be helpful to show? o Check what is needed to compile kernel-based examples over PPC 2.4. Philippe indicated that some switches are likely missing (x86 is fine already, other archs are 2.6-only). Some time ago I sent a patch for RTnet using the "kernel CFLAGS capturing" trick to get proper switches for 2.4: http://sourceforge.net/mailarchive/forum.php?thread_id=9493711&forum_id=24610 We could do the same trick here. Yeah, I had a look at this before. The point is that I would prefer to keep things _simple_ and self-contained. This capturing requires some helper Makefile and complex call nestings that likely only people with advanced make and shell skills can understand and adopt to their projects. I tend to agree on the "keep it simple" mantra, but still, there are at least two other aspects which are quite important too: - Nobody should expect to be able to develop a complete project only relying on paste-and-copy of example code. Since we are specifically talking about Makefile rules, we could not provide any set that would match everyone's project anyway, with respect to software and hardware requirements. Therefore, at some point, people really need to know what they are doing, which means that they should also know how to properly build out-of-tree modules with _their_ own 2.4 setup (well, if any "proper" solution exists, that is). And basically, I do hope that nobody starts implementing kernel modules without having - at least - a vague idea, about how to compile them for its platform in the first place... - Given that there is life beyond x86, we need to make sure that all Xenomai ports are considered equal, at least with respect to generic issues. Whilst it's ok to provide a x86-only 2.4 Makefile for compiling a x86-centric example, it's not for anything which could demonstrate a feature on any platform. This said, I agree that adding a fake module directory to capture the flags set by the main kernel Makefile is one step beyond ugliness; the other approach being to only provide a 2.6 Makefile frag. As 2007 approaches, I think that anyone still involved with projects relying on 2.4 kernels do know how to build 2.4 modules for the targeted platform. I think the example modules should compile on any platform and the "kernel CFLAGS capturing" trick is the most straight-forward way to do it for 2.4. It simplifies our life, avoids fiddling with various arch dependent flags in the Makefile, which will be even more ugly, and it serves as an example on how to get proper flags. Therefore I tend to add an appropriate script to the "scripts" subdirectory. But maybe things are that complicated already, and this is just different complexity. How do you compile simple out-of-tree modules against 2.4 PPC kernels? Are there any standard flags? Or is it different for each board or each compiler version or whatever? Jan ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help ___ 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 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. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [ANNOUNCE] Xenomai Example Repository
Jan Kiszka wrote: Wolfgang Grandegger wrote: Jan Kiszka wrote: Hi, the new Xenomai example repository has been created. I don't want to repeat here what is explained already on the related wiki page, please have a look at http://www.xenomai.org/index.php/Examples Instead, let me sketch what could be done next: o Port existing examples, snippets, demos from ksrc/skins/* over, make them compilable and runnable if required. o Identify what kind of examples are lacking. You, the user, is needed here. What do *you* think is missing, what would be helpful to show? o Check what is needed to compile kernel-based examples over PPC 2.4. Philippe indicated that some switches are likely missing (x86 is fine already, other archs are 2.6-only). Some time ago I sent a patch for RTnet using the "kernel CFLAGS capturing" trick to get proper switches for 2.4: http://sourceforge.net/mailarchive/forum.php?thread_id=9493711&forum_id=24610 We could do the same trick here. Yeah, I had a look at this before. The point is that I would prefer to keep things _simple_ and self-contained. This capturing requires some helper Makefile and complex call nestings that likely only people with advanced make and shell skills can understand and adopt to their projects. But maybe things are that complicated already, and this is just different complexity. How do you compile simple out-of-tree modules against 2.4 PPC kernels? Are there any standard flags? Or is it different for each board or each compiler version or whatever? I just cut and paste the flags from a kernel module make. For PPC, there are plenty of flags, not board but some are processor depended, but I'm unable to tell which one are really required. For this reason I like the module capturing trick. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] libnative versioning
On Fri, 2006-12-01 at 18:44 +0100, Gilles Chanteperdrix wrote: > Philippe Gerum wrote: > > > > The Xenomai ABI has been kept compatible between versions > > I am afraid you are being optimistic: I for one made some changes in the > posix skin that break the kernel/user interface. Sorry, I've been unclear: s,Xenomai ABI,Xenomai native interface ABI, > Maybe we need an ABI > revision for each skin ? > There is one for the nucleus already, so maybe we could extend the feature. This said, the point ABI revs is basically to detect potential mismatches; would an old POSIX app run improperly over the new library, or would it choke at startup? -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-help] Re: [Xenomai-core] [ANNOUNCE] Xenomai Example Repository
On Fri, 2006-12-01 at 18:22 +0100, Jan Kiszka wrote: > Wolfgang Grandegger wrote: > > Jan Kiszka wrote: > >> Hi, > >> > >> the new Xenomai example repository has been created. I don't want to > >> repeat here what is explained already on the related wiki page, please > >> have a look at > >> > >> http://www.xenomai.org/index.php/Examples > >> > >> Instead, let me sketch what could be done next: > >> > >> o Port existing examples, snippets, demos from ksrc/skins/* over, make > >>them compilable and runnable if required. > >> > >> o Identify what kind of examples are lacking. You, the user, is needed > >>here. What do *you* think is missing, what would be helpful to show? > >> > >> o Check what is needed to compile kernel-based examples over PPC 2.4. > >>Philippe indicated that some switches are likely missing (x86 is fine > >>already, other archs are 2.6-only). > > > > Some time ago I sent a patch for RTnet using the "kernel CFLAGS > > capturing" trick to get proper switches for 2.4: > > > > http://sourceforge.net/mailarchive/forum.php?thread_id=9493711&forum_id=24610 > > > > > > We could do the same trick here. > > Yeah, I had a look at this before. The point is that I would prefer to > keep things _simple_ and self-contained. This capturing requires some > helper Makefile and complex call nestings that likely only people with > advanced make and shell skills can understand and adopt to their projects. I tend to agree on the "keep it simple" mantra, but still, there are at least two other aspects which are quite important too: - Nobody should expect to be able to develop a complete project only relying on paste-and-copy of example code. Since we are specifically talking about Makefile rules, we could not provide any set that would match everyone's project anyway, with respect to software and hardware requirements. Therefore, at some point, people really need to know what they are doing, which means that they should also know how to properly build out-of-tree modules with _their_ own 2.4 setup (well, if any "proper" solution exists, that is). And basically, I do hope that nobody starts implementing kernel modules without having - at least - a vague idea, about how to compile them for its platform in the first place... - Given that there is life beyond x86, we need to make sure that all Xenomai ports are considered equal, at least with respect to generic issues. Whilst it's ok to provide a x86-only 2.4 Makefile for compiling a x86-centric example, it's not for anything which could demonstrate a feature on any platform. This said, I agree that adding a fake module directory to capture the flags set by the main kernel Makefile is one step beyond ugliness; the other approach being to only provide a 2.6 Makefile frag. As 2007 approaches, I think that anyone still involved with projects relying on 2.4 kernels do know how to build 2.4 modules for the targeted platform. > > But maybe things are that complicated already, and this is just > different complexity. How do you compile simple out-of-tree modules > against 2.4 PPC kernels? Are there any standard flags? Or is it > different for each board or each compiler version or whatever? > > Jan > > ___ > Xenomai-help mailing list > Xenomai-help@gna.org > https://mail.gna.org/listinfo/xenomai-help -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] libnative versioning
Philippe Gerum wrote: > > The Xenomai ABI has been kept compatible between versions I am afraid you are being optimistic: I for one made some changes in the posix skin that break the kernel/user interface. Maybe we need an ABI revision for each skin ? -- Gilles Chanteperdrix ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [ANNOUNCE] Xenomai Example Repository
Wolfgang Grandegger wrote: > Jan Kiszka wrote: >> Hi, >> >> the new Xenomai example repository has been created. I don't want to >> repeat here what is explained already on the related wiki page, please >> have a look at >> >> http://www.xenomai.org/index.php/Examples >> >> Instead, let me sketch what could be done next: >> >> o Port existing examples, snippets, demos from ksrc/skins/* over, make >>them compilable and runnable if required. >> >> o Identify what kind of examples are lacking. You, the user, is needed >>here. What do *you* think is missing, what would be helpful to show? >> >> o Check what is needed to compile kernel-based examples over PPC 2.4. >>Philippe indicated that some switches are likely missing (x86 is fine >>already, other archs are 2.6-only). > > Some time ago I sent a patch for RTnet using the "kernel CFLAGS > capturing" trick to get proper switches for 2.4: > > http://sourceforge.net/mailarchive/forum.php?thread_id=9493711&forum_id=24610 > > > We could do the same trick here. Yeah, I had a look at this before. The point is that I would prefer to keep things _simple_ and self-contained. This capturing requires some helper Makefile and complex call nestings that likely only people with advanced make and shell skills can understand and adopt to their projects. But maybe things are that complicated already, and this is just different complexity. How do you compile simple out-of-tree modules against 2.4 PPC kernels? Are there any standard flags? Or is it different for each board or each compiler version or whatever? 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] libnative versioning
On Fri, 2006-12-01 at 16:39 +0100, Jan Kiszka wrote: > Hi, > > we just had some fun here with incompatible native libraries. A program > was built against some 2.2 release and was then started on a target with > 2.3 libs installed. The result: undefined symbol rt_mutex_lock. The > reason: this function was renamed to rt_mutex_acquire in trunk to > resolve a naming conflict in recent kernels. > > So we now have incompatible libraries and should either increment some > version number of libnative or export the necessary aliases for > lock/unlock. What is preferred? The Xenomai ABI has been kept compatible between versions, so we want to provide the proper aliases for user-space; the conflict is kernel-space only, and there is no reason to ask user-space apps to conform to some obscure change that took place within the vanilla kernel API. Actually, I already wrappers in include/native/mutex.h, but unfortunately as macros, so dynamic binding could not work. I'm fixing this. Thanks. > > Jan > > ___ > Xenomai-core mailing list > Xenomai-core@gna.org > https://mail.gna.org/listinfo/xenomai-core -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [ANNOUNCE] Xenomai Example Repository
Jan Kiszka wrote: Hi, the new Xenomai example repository has been created. I don't want to repeat here what is explained already on the related wiki page, please have a look at http://www.xenomai.org/index.php/Examples Instead, let me sketch what could be done next: o Port existing examples, snippets, demos from ksrc/skins/* over, make them compilable and runnable if required. o Identify what kind of examples are lacking. You, the user, is needed here. What do *you* think is missing, what would be helpful to show? o Check what is needed to compile kernel-based examples over PPC 2.4. Philippe indicated that some switches are likely missing (x86 is fine already, other archs are 2.6-only). Some time ago I sent a patch for RTnet using the "kernel CFLAGS capturing" trick to get proper switches for 2.4: http://sourceforge.net/mailarchive/forum.php?thread_id=9493711&forum_id=24610 We could do the same trick here. o Regarding RTDM: driver patterns would be nice. Someone (who I don't recall ATM, sorry) once posted a template for a PCI driver. Feel invited to repost an updated version. Any further suggestion or ready code is welcome as well. Jan Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] libnative versioning
Hi, we just had some fun here with incompatible native libraries. A program was built against some 2.2 release and was then started on a target with 2.3 libs installed. The result: undefined symbol rt_mutex_lock. The reason: this function was renamed to rt_mutex_acquire in trunk to resolve a naming conflict in recent kernels. So we now have incompatible libraries and should either increment some version number of libnative or export the necessary aliases for lock/unlock. What is preferred? 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] Adeos support for 2.6.18 merged PowerPC architecture.
Paul wrote: > On Thursday 30 November 2006 13:19, Jan Kiszka wrote: >> 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? > > I have an x86_64 box waiting for a Xenomai port - I don't see much point in > hacking 2.6.17 and earlier when 2.6.19 is going to be a major change in key > areas.. It also looks like there is a closer integration of x86_64 and plain > old ix86 code in the 2.6.19 tree, so this may simplify the task of > maintaining a 64bit patch. For sure, there is not much point in starting on old code (the "stable" 2.6.16 series /may/ turn out to be an exception one day). An x86_64 port will be highly welcome! Feel invited to post I-pipe related topics also to [EMAIL PROTECTED] One hint that may ease testing/debugging: Have a look at qemu for x86_64. At least on x86, it already helped me a lot to debug weird kernel issues without long run-instrument-build-rerun cycles. All it takes is a minimal system image for a target. You can easily attach a debugger to the kernel, and you can even emulate SMP (though debugging is not perfect in that case). Of course, you cannot identify latency issues this way, but you will likely already be happy when things don't crash anymore. :) Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [ANNOUNCE] Xenomai Example Repository
Hi, the new Xenomai example repository has been created. I don't want to repeat here what is explained already on the related wiki page, please have a look at http://www.xenomai.org/index.php/Examples Instead, let me sketch what could be done next: o Port existing examples, snippets, demos from ksrc/skins/* over, make them compilable and runnable if required. o Identify what kind of examples are lacking. You, the user, is needed here. What do *you* think is missing, what would be helpful to show? o Check what is needed to compile kernel-based examples over PPC 2.4. Philippe indicated that some switches are likely missing (x86 is fine already, other archs are 2.6-only). o Regarding RTDM: driver patterns would be nice. Someone (who I don't recall ATM, sorry) once posted a template for a PCI driver. Feel invited to repost an updated version. Any further suggestion or ready code is welcome as well. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
