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
