[Xenomai-core] libnative versioning

[Xenomai-core] libnative versioning

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 517 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] libnative versioning

[Philippe Gerum]

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@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
-- 
Philippe.

Re: [Xenomai-core] libnative versioning

[Gilles Chanteperdrix]

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

Re: [Xenomai-core] libnative versioning

[Philippe Gerum]

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.

Re: [Xenomai-core] libnative versioning

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> 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?

The mismatch would occur if running the new library with an old kernel
or an old library with a new kernel, the pthread_cond_wait and
pthread_cond_timedwait syscalls have been replaced with
pthread_cond_wait_prologue/pthread_cond_wait_epilogue.

-- 
                                                 Gilles Chanteperdrix

[Xenomai-core] Re: libnative versioning

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]

Philippe Gerum wrote:
> 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.

And this fixes the fix (/wrt C++ users).

Jan

[-- Attachment #2: fix-mutex-c++.patch --]
[-- Type: text/plain, Size: 649 bytes --]

Index: include/native/mutex.h
===================================================================
--- include/native/mutex.h	(revision 1920)
+++ include/native/mutex.h	(working copy)
@@ -121,10 +121,6 @@ int rt_mutex_release(RT_MUTEX *mutex);
 int rt_mutex_inquire(RT_MUTEX *mutex,
 		     RT_MUTEX_INFO *info);
 
-#ifdef __cplusplus
-}
-#endif
-
 #ifdef __KERNEL__
 #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,18)
 static inline int __deprecated_call__ rt_mutex_lock(RT_MUTEX *mutex, RTIME timeout)
@@ -146,4 +142,8 @@ int rt_mutex_unlock(RT_MUTEX *mutex);
 
 #endif /* __KERNEL__ */
 
+#ifdef __cplusplus
+}
+#endif
+
 #endif /* !_XENO_MUTEX_H */

[Xenomai-core] Re: libnative versioning

[Philippe Gerum]

On Tue, 2006-12-05 at 17:44 +0100, Jan Kiszka wrote:
> Index: include/native/mutex.h
> ===================================================================
> --- include/native/mutex.h	(revision 1920)
> +++ include/native/mutex.h	(working copy)
> @@ -121,10 +121,6 @@ int rt_mutex_release(RT_MUTEX *mutex);
>  int rt_mutex_inquire(RT_MUTEX *mutex,
>  		     RT_MUTEX_INFO *info);
>  
> -#ifdef __cplusplus
> -}
> -#endif
> -
>  #ifdef __KERNEL__
>  #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,18)
>  static inline int __deprecated_call__ rt_mutex_lock(RT_MUTEX *mutex, RTIME timeout)
> @@ -146,4 +142,8 @@ int rt_mutex_unlock(RT_MUTEX *mutex);
>  
>  #endif /* __KERNEL__ */
>  
> +#ifdef __cplusplus
> +}
> +#endif
> +
>  #endif /* !_XENO_MUTEX_H */

Applied, thanks.

-- 
Philippe.