[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
openat status: new glibc emulation
From: |
Jim Meyering |
Subject: |
openat status: new glibc emulation |
Date: |
Sat, 12 Nov 2005 15:51:02 +0100 |
A few days ago, Ulrich Drepper and I were talking, and I mentioned
the openat[*] problem (that Solaris has it, but Linux doesn't, and
that it'd be so nice to be able to use it in places like fts.c,
mkdir-p.c, remove.c, etc.). Sure, we have replacement functions
in gnulib's lib/openat.c, and they work almost all of the time,
but not always. Well, he found a way to implement it using /proc
file system support, and now it's in glibc. No fchdir needed.
This means that an openat-based rm command can now work on Linux as
well as on Solaris, when run from an unreadable working directory.
So progressive glibc-based systems will soon provide openat et al.
Thanks, Uli!
FYI, the trick is to realize that openat (FD, filename, ...) is
the same as calling open ("/proc/self/fd/NNN/FILENAME", ...) --
when you have /proc support.
This is a great complement to the existing save_cwd/restore_cwd
technique, since it lets us avoid changing away from the current
directory most of the time -- the only drawback is that glibc's
openat emulation relies on procfs support. If /proc is unavailable
or inaccessible, that emulation fails, so we still need to fall
back on using save_cwd and restore_cwd.
Note: with this new openat emulation in glibc, we'll have to
change gl_FUNC_OPENAT not to test solely for the presence of the
openat function, since the gnulib emulation has to supersede
the glibc one.
I've just change coreutils' lib/openat.c to do this:
2005-11-12 Jim Meyering <address@hidden>
Emulate openat-family functions using Linux's procfs, if possible.
Idea and some code based on Ulrich Drepper's glibc changes.
* openat.c: (BUILD_PROC_NAME): New macro.
Include <stdio.h>, <string.h>, "alloca.h" and "intprops.h".
(rpl_openat): Emulate by trying to open /proc/self/fd/%d/%s,
before falling back on save_cwd and restore_cwd.
(fdopendir, fstatat, unlinkat): Likewise.
These openat-family functions should be implemented in every kernel,
and I suppose eventually, they will be -- in the ones that matter.
In the mean time, the overhead of using their replacements is minimal,
and they work under almost all circumstances, even on systems without
procfs support.
[*] I've harped about this before. E.g., here:
<http://lists.gnu.org/archive/html/bug-coreutils/2005-04/msg00124.html>
Plus, I've finally written to the linux-kernel list,
<http://www.ussg.iu.edu/hypermail/linux/kernel/0511.1/1648.html>
requesting that they consider adding support for openat et al.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- openat status: new glibc emulation,
Jim Meyering <=