El Dilluns, 26 de gener de 2015, a les 15:01:27, Philippe Gerum va escriure: > On 01/26/2015 01:39 PM, Leopold Palomo-Avellaneda wrote: > > Maybe I'm wrong. But after reading this thread I understood that to have a > > kernel with both patches (i-pipe and preempt_rt) and, I understand, > > Xenomai-3 with the two versions could be a very interesting system to > > work on. > > > > For instance, I'm in the robotics field, and after that mails I thought > > that it could be a good solution that fit the cases where you have > > several loops, with several rates with different importance. > > You are missing an important point: Xenomai 3 over Mercury is about > running non-POSIX RTOS APIs over a native kernel (with or without > preempt-rt, this is orthogonal to the issue).
this is an interesting point. [...] > > Therefore, your proposal mainly addresses the issue of running a mixed > configuration, with some Mercury-based application(s) ported from a > traditional RTOS to linux, and other application(s) running over Cobalt > in dual kernel mode, concurrently on the same system. People who just > want to run POSIX apps over a native kernel don't need Xenomai 3. In > short, the potential user base for the mixed setup as described is quite > small. > > With that in mind, using a mixed installation root between Mercury and > Cobalt also means that any 2.x Makefile currently using "xeno-config" > would have to be fixed up, to reflect the new suffixed path or call > pkg-config to retrieve it, whatever fits. We have been advertising > xeno-config since years, as a mean to stay away from installation > specifics, so this would be quite wrong to end up asking people to run > xeno-config-cobalt or xeno-config-mercury. xeno-config --with-core=cobalt/mercury could be a solution. But, some default core should be defined. > As I mentioned already, we won't go for single binaries running over > both cores, the performance and maintenance impact would be a nightmare. Yes, two types of binaries. Your argumentation was clear. > Since all our build system is autoconfiscated, you can pick any root > prefix that makes sense, and even fine tune every installation directory > already (lib, include, bin etc). This means that having multiple roots > is definitely a non-issue, and does not introduce any limitation. > > I don't buy the "suffix to disambiguate" argument either: > /usr/lib/libvxworks-m.so is not clearer than > /usr/lib/mercury/libvxworks.so, or > /usr/xenomai/mercury/lib/libvxworks.so. And this does not even work > better with /usr/lib/libvxworks-mercury.so. > > Besides, there is no shortage of ways to find out which Xenomai > configuration your build system and even your application is currently > depending on. well, I usually ask to ldd. So, if I have a binary and I run: ldd /usr/local/lib/libcpp4ec.so linux-vdso.so.1 (0x00007fffee0dc000) libsoemrt.so.1.3.0 => /usr/local/lib/libsoemrt.so.1.3.0 (0x00007feea2352000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007feea214a000) libnative.so.3 => /usr/lib/libnative.so.3 (0x00007feea1f40000) libxenomai.so.0 => /usr/lib/libxenomai.so.0 (0x00007feea1d39000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007feea1b1c000) libpugixml.so.1 => /usr/lib/x86_64-linux-gnu/libpugixml.so.1 (0x00007feea18e7000) librtdm.so.1 => /usr/lib/librtdm.so.1 (0x00007feea16e5000) for example, if I had libvxworks-cobalt there, I knew that my binary was built against xenomai with cobalt. > The only requirement is to query the right xeno-config > script or application, which may be as simple as setting the PATH > variable appropriately for your setup: > > $ xeno-config --core > mercury > $ xeno-config --cflags [...] Yes, I liked. I thought that it was a good solution but I don't know if it's fhs, if follow debian/fedora policies for instance. That's all. It was my first idea to propose you but I asked and to put libraries in places non- standards isn't a good idea. I'm investigating it. But, for instance in debian mentors irc they found it "Sounds suspicious" Best regards, Leopold -- -- Linux User 152692 GPG: 05F4A7A949A2D9AA 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? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150126/02693e57/attachment.sig> _______________________________________________ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai