On Wed, Mar 21, 2007 at 10:54:36AM +0100, Pierre.Peiffer@bull.net wrote:> This last patch is an adaptation of the sys_futex64 syscall provided in -rt> patch (originally written by Ingo Molnar). It allows the use of 64-bit futex.> > I have re-worked most of the code to avoid the duplication of the code.> > It does not provide the functionality for all architectures (only for x64 for now).

I don't think you should blindly add all operations to sys_futex64 withoutthinking what they really do.E.g. FUTEX_{{,UN,TRY}LOCK,CMP_REQUEUE}_PI doesn't really make any sense for 64-bitfutexes, the format of PI futexes is hardcoded in the kernel and is always32-bit, see FUTEX_TID_MASK, FUTEX_WAITERS, FUTEX_OWNER_DIED definitions.exit_robust_list/handle_futex_death will handle 32-bit PI futexes anyway.Similarly, sys_futex64 shouldn't support the obsolete operations thatare there solely for compatibility (e.g. FUTEX_REQUEUE or FUTEX_FD).

When you just -ENOSYS on the PI ops, there is no need to implementfutex_atomic_cmpxchg_inatomic64.

FUTEX_WAKE_OP is questionable for 64-bit, IMHO it is better to just-ENOSYS on it and only if anyone ever finds actual uses for it, add it.

For 64-bit futexes the only needed operations are actuallyFUTEX_WAIT and perhaps FUTEX_CMP_REQUEUE, so I wonder if it isn'tbetter to just add FUTEX_WAIT64 and FUTEX_CMP_REQUEUE64 ops to sys_futexinstead of adding a new syscall.

But the FUTEX_{{,UN,TRY}LOCK,CMP_REQUEUE}_PI removal for 64-bit futexesis IMHO the most important part of my complain.