I ended up forgetting to remove some kprintfs from device.c that were inserted
during Xen's blkfront development

Do to __xstat* what commit 018c672e
did to __fxstat* - they had the same problem.

In Linux, _STAT_VER is 1 on 64-bit (and 3 on 32-bit), but glibc never
verifies the argument to __fxstat64. JNR - a library used by JRuby -
wrongly (I believe) passes ver==0 to __fxstat64
(see jnr-posix/..../LinuxPosix.java). On Linux this wrong argument is
ignored but in our implementation, fails the check.

So this patch removes this check from our code as well, to let JNR and
therefore JRuby which uses it, use stat without failing.

Currently the umask is ignore (it's pointless since we have no users).

Needed by JRuby.

If dup3() is called with oldfd pointing to an existing file, it will close
the file for us.  37988879 converted fd operations to RCU, which caused
this close to be deferred until after the RCU grace period (43df74e7 fixed
this, but only for close(), not for dup3).

The asynchronous operation of dup3() should be fine, except that it triggers
a bug in sys_rename(): if the reference count of the vnode for either the
source or destination is elevated, rename fails with EBUSY.  This is due to
the coupling between vnodes and pathnames and can be fixed with the move
to separate dentries.

The whole sequence looks like

0xffffc000de90c010  3   1376912988.418660 vfs_lseek            95 0x0 0
0xffffc000de90c010  3   1376912988.418661 vfs_lseek_ret        0x0
0xffffc000de90c010  3   1376912988.418689 vfs_dup3             93 95 0x0
0xffffc000de90c010  3   1376912988.418696 vfs_dup3_ret         95
0xffffc000de90c010  3   1376912988.418711 vfs_close            95
0xffffc000de90c010  3   1376912988.418711 vfs_close_ret
...
0xffffc000de90c010  3   1376912988.420573 vfs_close            95
0xffffc000de90c010  3   1376912988.420580 vfs_close_ret
0xffffc000de90c010  3   1376912988.420738 vfs_rename           "/usr/var/lib/cassandra/data/system/local/system-local-tmp-ic-1-Index.db" "/usr/var/lib/cassandra/data/system/l
ocal/system-local-ic-1-Index.db"
0xffffc000de90c010  3   1376912988.422302 vfs_pwritev_ret      0x56
0xffffc000de90c010  3   1376912988.422302 vfs_rename_err       16

fd 95 (as it was before dup3) is still open at the time of the rename.

Fix by not deferring the fdrop() in fdset(); 43df74e7 already made fdrop()
safe to use directly.

Fixes failures with Cassandra.

v_path will go away once the vnode cache uses numeric indices for hardlink
support.

We'll need this for any pathname related actions.

Create a new dentry structure for pathname components, following the Linux
VFS model.  The vnodes are left-as is for now but are always fronted by
dentries for pathname lookups.  In a second step they will be moved to
use non-pathname indices.

[penberg: fix open(O_CREAT|O_EXCL) breakage ]

We'll pass the file to the open method soon, so make sure it's fully
constructed.

These aren't used in the build and will bitrot badly once
changing the VFS significantly.

This is used by subr_disk during bio flush operation

There are many other bio fields and functions that blkfront uses that are
not provided by our simplified bio. I am adding them here. One of the things we need is
a type definition of daddr_t. This already exists in fatfs.h, but it makes more sense to
live in the lower level code. So instead of including fatfs in bio.h, I am including
bio.h in fatfs and moving the daddr_t definition here.

Some block devices, such as the Xen blkfront, will have a maximum per-request size
that needs to be obeyed. In order for us to do it, we'll need to be aware of this
requirement in upper layers. So set up the device with it. We initialize the default
structure to make sure only interested parties need to set this up.

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