linux-user: include <linux/fcntl.h> for F_EXLCK and F_SHLCK

The F_EXLCK and F_SHLCK fcntl lock constants are obsolete synonyms for F_WRLCK and F_RDLCK. Include <linux/fcntl.h> to fix compilation with the musl c library, which does not expose these constants.

---
 linux-user/syscall.c | 1 +
 1 file changed, 1 insertion(+)

index 0815f30..3d1f694 100644
@@ -107,6 +107,7 @@ int __clone2(int (*fn)(void *), void *child_stack_base,
 #include <linux/if_bridge.h>
 #endif
 #include <linux/audit.h>
+#include <linux/fcntl.h>
 #include "linux_loop.h"
 #include "uname.h"
 

2.7.3

This seems unlikely, since on for instance Alpha F_EXLCK is 16, F_SHLCK is 32, F_RDLCK is 1 and F_WRLCK is 2, so they're all distinct:
http://lxr.free-electrons.com/source/arch/alpha/include/uapi/asm/fcntl.h#L52

thanks
-- PMM

Except for headers, the only use of F_EXLCK in the kernel is in fs/cifs/file.c, where it has the same effect as F_WRLCK (except for a debug message). Similarly for F_SHLCK and F_RDLCK.

Thanks,
Felix

I've now looked at linux-1.0, linux-2.0 and linux-2.4. In all of them, the constants are used in fs/locks.c. In linux-1.0, F_SHLCK has almost the same effect as F_RDLCK, except that F_SHLCK accepts also files with write but without read permission. Similarly for F_EXLCK. In linux-2.0 when F_EXLCK or F_SHLCK are used, the flag F_BROKEN gets set. Finally, in linux-2.4 they just lead to EINVAL.

So I guess that the commit message should more accurately say that the constants were used in the past for a broken flock implementation.

With this closer look at the history of these constants, it is also not clear to me whether qemu should care at all about translating them.

Felix