On Sat, Sep 6, 2008 at 4:16 PM, Petr Salinger <Petr.Salinger@xxxxxxxxx> wrote: >> Do you have any other concerns? > > The versioning does not help here, i.e. in the above case > bar will not reference any old (linuxthread variant) function, > therefore it would look like there is no need for compat code, even though > it will be still needed. Yes, I agree with you, but you still need symbol versioining. The point of versioning the symbols is so that in the future when you run an old program you will get the error "Undefined reference to symbol foo" instead of a random crash. So the procedure is this: 1. Create an old compat function at version 2.0, which is only compiled if oldest ABI is 2.0. 2. Create a new function at version 2.8, which *also* contains compat code wrapped in "#if SHLIB_COMPAT (libpthread, GLIBC_2_0, GLIBC_2_8)". With oldest-abi at 2.0, all functions will have the compat checks enabled, allowing mixing of old applications and new libraries. Eventually when you build with oldest ABI 2.8, the 2.0 version functions are gone, the compat code in 2.8 version functions is dropped, and everything is working optimally. When you run an old application it complains "Undefined reference to symbol foo", and rightly so because we only support the new ABI. Do you see any problem with that? > For dropping compat code, you have to be sure any package is not compiled > against old glibc - it can be determined in debian from Depends: line > in binary package control file. The strategy for upgrade might be easy; > For lenny+1 include compat code, but make sure all of lenny+1 released > packages are build against NPTL variant. The compact code can be dropped > just after lenny+1 release. Yes, that's probably a good procedure. However, you can't determine it from the depends line because libc is an implicit depend? I believe you have to analyze the binaries in the archive. > It looks like one compare will say it is not LT initialized lock, > this path might be really fast. > IMHO, even including such compat code forever will be easier compared to > transition all libraries ... Yes, I agree. > The check_and_reset() should be reasonably "atomic" - two threads might call > pthread_mutex_lock() on static LT initialized lock in the same time. It will be 100% atomic, we will use hppa's load-and-clear-word instruction to analyze the contents of the old lock structure. > What are the difference between LT and NPTL definition of pthread_mutex_t. > Only 3 unused ints in pthread_mutex_t ? A function that takes as an argument a structure that has no padding left for a new 4-byte int aligned lock and contains a statically initialized __atomic_lock_t that we must reuse for our lock. We must review these structures for possible padding to use as a lock word: pthread_cond_t pthread_mutex_t pthread_rwlock_t pthread_barrier_t pthread_spinlock_t >From this list, only those that have static initializers may cause an ABI issue, namely: PTHREAD_COND_INITIALIZER PTHREAD_MUTEX_INITIALIZER PTHREAD_RWLOCK_INITIALIZER (Deleted in issue 6) Lastly the complete list of functions that may need compat: pthread_cond_timedwait pthread_cond_wait pthread_mutex_destroy pthread_mutex_getprioceiling pthread_mutex_init pthread_mutex_lock pthread_mutex_setprioceiling pthread_mutex_timedlock pthread_mutex_trylock pthread_mutex_unlock pthread_cond_broadcast pthread_cond_destroy pthread_cond_init pthread_cond_signal pthread_cond_timedwait pthread_cond_wait pthread_rwlock_destroy pthread_rwlock_init pthread_rwlock_rdlock pthread_rwlock_timedrdlock pthread_rwlock_timedwrlock pthread_rwlock_tryrdlock pthread_rwlock_trywrlock pthread_rwlock_unlock pthread_rwlock_wrlock Please feel free to review my list. I based this list on the data here: http://www.opengroup.org/onlinepubs/009695399/ Cheers, Carlos. -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
