Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
> > Jan Kiszka wrote:
> > > Gilles Chanteperdrix wrote:
> > > > Philippe Gerum wrote:
> > > > > Gilles Chanteperdrix wrote:
> > > > > > Since binding of the semaphore heaps is now made by
> > xeno_skin_bind, there is
> > > > > > much less modifications in src/skins/posix/init.c. However, I
> > had to do
> > > > > > something really ugly: since binding the semaphore heaps by
> > xeno_skin_bind
> > > > > > requires calls to open, ioctl, mmap, close and munmap, I
> > redefined these symbols
> > > > > > to be the __real_ variants before including bind.h.
> > > > >
> > > > > Is there any upside to do this instead of simply calling the
> > __real_*
> > > > > placeholders, since we do already provide weak wrappers for those
> > when the
> > > > > linker's wrapping magic is not invoked?
> > > >
> > > > The point is that the wrappers and linker magic only take place for
> > > > POSIX skins. Other skins have to call the genuine open, ioctl, mmap,
> > > > close and munmap services.
> > >
> > > What about controlling the desired prefix for generic functions in
> > > bind.h via some #define that the caller has to/can set before including
> > > the header:
> > >
> > > #define POSIX_PREFIX __real_
> > > #include <asm-generic/bits/bind.h>
> > >
> > > and there we would have:
> > >
> > > POSIX_PREFIX##open(...);
> > >
> > > Looks a bit cleaner to me.
> >
> > Well, in this case we end up cluttering the code with the POSIX_PREFIX
> > macro, even in the non posix case where no prefix is needed.
>
> Yes, but there are only few spots. The advantage of this strategy is
> that it is explicit in-place (ie. inside bind.h). That avoids potential
> collateral damage in the future when other services are added to that
> helper which shall not be wrapped.
Actually, the only important call is open. Since once the file
descriptor has been created with __real_open, all syscall wrappers will
automatically fall back to the __real syscall variants.
--
Gilles.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
