[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comment on glibc2.28: Re: [PATCH glibc] Add file record locking supp

From: Svante Signell
Subject: Re: Comment on glibc2.28: Re: [PATCH glibc] Add file record locking support
Date: Mon, 03 Dec 2018 16:01:37 +0100
User-agent: Evolution 3.30.0-1

On Sat, 2018-12-01 at 19:30 +0100, Samuel Thibault wrote:
> I forgot here:

Is this really needed? From git-fcntl64.diff:
Index: glibc-2.28/sysdeps/mach/hurd/fcntl.c
--- glibc-2.28.orig/sysdeps/mach/hurd/fcntl.c
+++ glibc-2.28/sysdeps/mach/hurd/fcntl.c
@@ -215,3 +210,4 @@ strong_alias (__libc_fcntl, __libc_fcntl
 libc_hidden_def (__libc_fcntl64)
 weak_alias (__libc_fcntl64, __fcntl64)
 libc_hidden_weak (__fcntl64)
+weak_alias (__fcntl64, fcntl64)

Index: glibc-2.28/sysdeps/mach/hurd/fcntl64.c
--- /dev/null
+++ glibc-2.28/sysdeps/mach/hurd/fcntl64.c
@@ -0,0 +1 @@
+/* fcntl64 is defined in fcntl.c as an alias.  */

Additionally, sysdeps/mach/hurd/flock.c calls __file_lock() and the file-record-
locking patches need to patch lib{diskfs,netfs,trivfs} file-lock.c files too.

It would be much simpler to use sysdeps/posix/flock.c that calls fcntl()
directly, and scratch sysdeps/mach/hurd/flock.c as well as 
in due time.

What about libtreefs/s-file.c:treefs_S_file_lock() and it's hooks?
What it the main usage application of libtreefs?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]