For xen, I would like to use an already existing device instead of creating one.
I still need to register it, though. I am here factoring out device_create in
a allocation and a registering part so I can use the later by itself.

Currently, we perform the final fdrop() in an rcu callback, which means it
can have considerable latency.  This in turn places restrictions on
further optimizations we can do to rcu, as we need prompt close() execution.

Relax this by performing the fdrop() immediately, and only deferring the
final free().  To do this, we harden fget() so it now expects files with
positive refcounts, and make sure that after the final fdrop() refcounts
are either zero or negative.

This also makes close() take effect immediately, which fixes tst-pipe.so.

This patch changes fget() to no longer take gfdt_lock, using rcu instead.

For rcu.

Posix doesn't require a writeable file descriptor for fsync, and all common
operating systems allow fsync on a non-writable fd, as this is required
to synchronize directory operations.

Also fix up the indentation in sys_fsync a bit.

Suggested by hch.

The off_t cast are just superflous, the int cast causes actual truncatation
bugs.

We can't include osv/poll.h from osv/file.h. It's not needed there,
and causes a mess now that I added a use of BSD's "struct mtx" to
poll.h (because it turns out we have code using <osv/file.h> and using
the name "mtx" for something else).

After removing the unneeded include of <osv/poll.h> from osv/file.h,
we need to add include <sys/poll.h> to a few additional source files
(note include of sys/poll.h, not osv/poll.h).

readdir_r doesn't want errno set at all, and readdir does by itself already.

lseek() crashes when used on pipes, sockets, and now also fd 0, 1 or 2
(the console), because they don't have an underlying vnode. No reason
to assert() in this case, should just return ESPIPE (like Linux does
for pipes, sockets and ttys).

Similarly, fsync, readdir and friends, fchdir and fstatfs shouldn't
crash if given a fd without a vnode, and rather should return the
expected error.

We had a bug where a read() on the console (fd 0) would block writes to
the console (fd 1 or 2). This was most noticable when background threads
in the CLI tried to write output, and were blocked until the next keypress
because the blocking read() would lock the writes out.

The bug happens because we opened the console using open("/dev/console")
and dup()'ed the resulting fd, but this results, in the current code, in
every read and write to these file descriptors to pass through vfs_read()/
vfs_write(), which lock a single vnode lock for all three file descriptors -
leading to write on fd 1 blocking while read is ongoing on fd 0.

This patch doesn't fix this vnode lock issue, which remains - and should
be fixed when the devfs or vfs layers are rewritten. Instead, this patch
adds a *second API* for opening a console which doesn't go through the
vnode or devfs layers:

A new console::open() function returns a file descriptor which implements
the correct file operations, and is not associated with any vnode.

The new implementation works well with write() while read() is ongoing.

Note that poll() support was missing from the old implementation (it
seems it can't be done with the vnode abstraction?) and is still missing
in the new implementation, although now shouldn't be hard to add
(need to implement the poll fileops, and to use poll_wake() in the
line-discipline function console_poll).

Sorry, missing unsupported_poll broke compilation after the previous patch

Eclipse recognizes .mk as a makefile, make it easier for new users to
use eclipse.

We could benefit from the console being ready a bit earlier. The only
dependency that I see to it are the interrupts that need to be working.  So as
soon as we initialize the ioapic, we should be able to initialize the console.

This is not the end of story: we still need an even earlier console to debug the
driver initialization functions, and I was inclined to just leave console_init
where it is, for now.

But additionally, I felt that loader is really a more appropriate place for
that than vfs_init... So I propose we switch. In the mean time, it might help
debug things that happen between ioapic init and the old vfs_init (mem
initialization, smp bring up, etc)

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>

In order to optimize the fast path of tracepoints, we need to patch
the call sites to skip calling the slow path code completely.  In turn,
that requires that each call site be unique -- a separate function.

In the current implementations, tracepoints with the same signature map
to the same type.  It would have been great to use the name as a discriminant
(tracepoint<"sched_queue", thread*> trace_sched_queue(...);), but C++ does
not support string literals as template arguments.

We could do

  const char* trace_sched_queue_name = "sched_queue";
  tracepoint<trace_sched_queue_name, thread*> trace_sched_queue(...);

but that doubles the code for declaring a tracepoint.  Add a unique ID instead
(and code to verify it is unique).

Previous commit broke the build, because I forgot to commit a file.

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).

Avi recently added extern "C" to pwrite64 (after the header change apparently
removed this declaration from the header file). Also do this to pread64 -
otherwise the "derby" benchmark (from SPECjvm2008) cannot run.