New system call wanted: fdreopen

[Tristan Wibberley]

Hello,

I'd like to propose a system call called "fdreopen":

  int fdreopen(int src_fd, int dst_fd, int flags);


I am willing to try implementing this system call given some suggestions 
where to start and what locking to watch out for. I have given a brief of 
the behaviour below, and a description of the class of problem that it 
solves at the end.

Does anybody know any reasons why this system call would be impossible/
impractical or otherwise unacceptable?

Any improvements I should consider before trying to implement it?


Behaviour
=========

This system call would be like dup3 except for these things:

 - if dst_fd is -1 then the lowest available file descriptor is allocated
   rather than returning EBADF as dup3 does.

 - the new file descriptor points to a *new* entry in the file table much
   as if the original file had been opened again via open or openat. This
   means that two large independent libraries can seek and read without
   synchronising even when they cannot open a file by its path.

 - O_RDWR access can be reduced to O_RDONLY or O_WRONLY:
    int src_fd = open("/file", O_RDWR | O_CLOEXEC);
    new_fd = fdreopen(src_fd, -1, O_CLOEXEC | O_RDONLY);

 - it would be async signal safe.


Why
===

A common idiom on Linux is to open a file and keep the fd open so that 
the underlying file can be unlinked from its directory. But if the file 
needs to be read from several different parts of the codebase then due to 
the file descriptor having exactly one read pointer those different parts 
must be synchronised which is a relatively difficult task.

I think that this new system call is required to achieve that neatly and 
simply:

- dup does not solve this problem because it only allows the new file
  descriptor to have its own flags (eg O_CLOEXEC).

- /proc/self/fd/* does not solve this problem because the file might no
  longer be available at the same place in the filesystem. In some
  otherwise simple message passing or ReSTful IPC a different file will
  be available at that path.

I suspect that user space has been solving this problem with otherwise 
unnecessary levels of either synchronisation or difficult to reproduce 
occasional bugs.

-- 
Tristan Wibberley

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/