- May 31, 2013
-
-
Guy Zana authored
also, it's better to call poll_wake() with both POLLIN/OUT and POLLRDNORM/POLLWRNORM, just to be on the safe side. seen a few references in the jdk.
-
Guy Zana authored
-
Guy Zana authored
-
Guy Zana authored
-
Christoph Hellwig authored
-
Christoph Hellwig authored
We need to ifdef out more unused code to not make gcc complain.
-
- May 30, 2013
-
-
Nadav Har'El authored
This patch adds pipe(). The pipes are built using the same FIFO implementation, "af_local_buffer", as used by the existing unix-domain socketpair implementation - while the socket-pair used two of these buffers, a pipe uses one. This implementation deviates from traditional POSIX pipe behavior in two ways that we should fix in followup-patches: 1. SIGPIPE is not supported: A write to a pipe whose read end is closed will always return EPIPE, and not generate a SIGPIPE signal. Programs that rely on SIGPIPE will break, but SIGPIPE is completely out of fashion, and normally ignored. 2. Unix-style "atomic writes" are not obeyed. A write(), even if smaller than PIPE_BUF (=4096 on Linux, whose ABI we're emulating), may partially succeed if the pipe's buffer is nearly full. Only a write() of a single byte is guaranteed to be atomic. We hope that Java doesn't rely on multi-byte write() atomicity (single-byte writes are enough for waking poll, for example), and users of Java's "Pipe" class definitely can't (as Java is not Posix-only), so we hope this will not cause problems. Fixing this issue (which is easy) is left as a TODO in the code. Additionally, this patch marks with a FIXME (but doesn't fix) a serious bug in the code's iovec handling, so writev() and readv() are expected not to work in this version of pipe() - and also on the existing socketpair.
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
Christoph Hellwig authored
We don't have temporary snapshots yet, and we probably never will have processes that could exit.
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
Christoph Hellwig authored
It clashes with a macro of the same name in OSv.
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
Christoph Hellwig authored
OSv isn't ready for this yet.
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
Christoph Hellwig authored
-
Nadav Har'El authored
Previous commit broke the build, because I forgot to commit a file.
-
Nadav Har'El authored
Previously, we re-implemented "unsupported" file operations (e.g., chmod for a pipe on which fchmod makes no sense) several times - there was an implementation only for chmod in kern_descrip.c, used in sys_socket.c, and af_local.cc had its own. As we add more file descriptor type (e.g., create_epoll()) we'll have even more copies of these silly functions, so let's do it once in fs/unsupported.c - with the fs/unsupported.h header file. This also gives us a central place to document (and argue) whether an unimplemented ioctl() should return ENOTTY or EBADF (I think the former).
-
Nadav Har'El authored
If poll() was waiting on a file descriptor from socketpair_af_local, we would never wake it up, and an example of this is the failure in a recently committed fix to tst-af-local.cc. The problem is that when one writes to one end of the socket, we need to call wake_poll() on the other end of the socket, so we need to remember which "struct file *" is attached to each end of the af_local_buffer objects. What I did is what I thought the most elegant solution is: Rather than having "sender" and "receiver" of af_local_buffer booleans, they are now "struct file *". I added new functions, attach_sender(f) and attach_receiver(f), which set the file* we'll need to notify for each end; These functions are analogous to functions detach_sender, detach_receiver that we already had. After each interesting event - read, write, close, etc - we notify the appropriate file*, using poll_wake. attach_sender(f) and attach_receiver(f) is called by af_local_init(f) - which used to be empty and now does something. Note how af_local_init(f) only does send->attach_sender(f) and receive->attach_receiver(f), but doesn't touch the two others (send->attach_receiver, receive->attach_sender) - these other two are set when the second file descriptor, with the send and receive fifos in reversed roles, is initialized with its af_local_init. After this fix, the new af_local_test works correctly.
-
Nadav Har'El authored
The tst-af-local.so test supposedly tested a waiting poll() on a unix-domain socketpair, but unfortunately the test was incorrect - the writer thread usually (even always) manged to write to the socket before poll() started, so poll() never actually had to wait and always returned immediately. But it turns out, when we really do need to wait, there *is* a bug: poll() doesn't wake up when input arrives. So this patch fixes the *test* to demonstrate the bug. After this fix, the tst-af-local.so test now fails. I'll fix the bug, to make the test pass again, in a followup patch.
-
- May 29, 2013
-
-
Nadav Har'El authored
Don't abort on an unimplemented sysconf parameter. One of the documented functions of sysconf(3) is to "test ... whether certain options are supported", so programs are free to test for features we don't support yet, and we're supposed to return -1 with errno set to EINVAL. For example, Boost tested _SC_THREAD_SAFE_FUNCTIONS which we didn't support. It would have been fine if we set EINVAL (it would switch from *_r functions to the non-reenatrant ones) - but it wasn't fine that we abort()ed because of this test :-) To be on the safe side, this patch still prints a message if we see an unknown sysconf - in case in the future we'll come across a new one we must treat. But eventually, the message should go away too.
-
Nadav Har'El authored
Implement the _SC_THREAD_SAFE_FUNCTIONS sysconf, returning 1. _SC_THREAD_SAFE_FUNCTIONS is defined in Posix 1003.1c ("posix threads"), and is supposed to return 1 if the thread-safe functions option is supported (*_r() functions). Since we do implement those, we should return 1 for this sysconf. Boost's system library uses this sysconf, and if it sees it is not available, restorts to the _r()-less variants, for no good reason.
-
Nadav Har'El authored
This patch implements readdir64, as an alias to readdir. We can do this, because on 64-bit Linux, even the ordinary struct dirent uses 64-bit sizes, so the structures are identical. The reason we didn't miss this function earlier is that reasonable applications prefer to use readdir64_r, not readdir64. Because Boost filesystem library thought we don't have the former (see next patch for fixing this), it used the latter.
-
Nadav Har'El authored
Say we also implement librt.so.1. This is required, for example, by the Boost libraries (e.g., libboost_system-mt.so.1.50.0). The librt library isn't actually a separate library on modern Linux - rather all its traditional functions are now in glibc, and "librt" is merely a filter on glibc. So no reason not to say we support librt too. Not to mention that we already implement a bunch of functions that traditionally resided in librt (nanosleep, sched_yield, sem_*, etc.
-
Nadav Har'El authored
Added a simple readdir() and readdir_r() test. The test is successful - it turns out readdir() had no bug, and the bug was in mkbootfs.py, but since I already wrote the test I guess might as well add it.
-
- May 28, 2013
-
-
Nadav Har'El authored
getsockname() used to fail because by the time the call chain reached kern_getsockname() it got addrlen=0. The problem is getsockname1() which gives it an initialized local variable instead of the given addrlen. Most of these layers and copies are redundant, and are only left because of previous incarnations of the code which had copies from user space - but we need to at least get the unnecessary copies right ;-)
-
Nadav Har'El authored
Java.so used to correctly support the "-jar" option, but did not fully allow the other "mode" of running Java: specifying a class name which is supposed to be searched in the class path. The biggest problem was that it only know to find class files, but not a class inside a jar in the class path - even if the classpath was correctly set. Unfortunately, fixing this C code was impossible, as JNI's FindClass() simply doesn't know to look in Jars. So this patch overhauls java.so: Java.so now only runs a fixed class, /java/RunJava.class. This class, in turn, is the one that parses the command line arguments, sets the class path, finds the jar or class to run, etc.. The code is now much easier to understand, and actually works as expected :-) It also fixes the bug we had with SpecJVM2008's "compiler.*" benchmarks, which forced us to tweak the class path manually. The new code supports running a class from the classpath, and also the "-classpath" option to set the class path. Like the "java" command line tool in Linux, this one also recognizes wildcard classpaths. For example, to run Jetty, whose code is in a dozen jars in /jetty, one can do: run.py -e "java.so -classpath /jetty/* org.eclipse.jetty.xml.XmlConfiguration jetty.xml"
-