Support O_PATH for open() (XCC)
authorBarret Rhoden <brho@cs.berkeley.edu>
Thu, 10 Sep 2015 19:02:36 +0000 (15:02 -0400)
committerBarret Rhoden <brho@cs.berkeley.edu>
Mon, 28 Sep 2015 19:14:00 +0000 (15:14 -0400)
commita85ac2bf79d1ec86f1f55aa5486bf13071330864
tree31b970e0b468847b1e840da55943308796c7ed9a
parent7808fbf9fae44248fcd2c5505e65948fe756b2ff
Support O_PATH for open() (XCC)

Opening a path with O_PATH, which is also supported in Linux, walks to
an FD, grabs the chan, and refers to an object, but it does not fully
open the object for I/O.  Our O_PATH is similar to Linux's and can
eventually be used for openat().

The particular meaning of O_PATH will depend on the devices.  At a bare
minimum, FDs opened with O_PATH are not able to be used for I/O; they
have no access permissions.  They both refer to a location (path) in the
namespace, as well as refer to the object underneath.

In earlier versions of this code, I just did a namec() without the
device open or any device op.  You'd have an FD that pointed to a chan.
However, that chan was one of the kernel-only intermediate chans (9ns
uses them all the time).  The chan had a QID and a device ID, which
uniquely identifies the object, but that object had no permanence.  In
the case of #I, it did not grab a reference to the conversation, so it
was possible that the object would disappear!  (Or in the case of #I,
just be reused for another conversation).  Considering we are supposed
to be able to perform some non-I/O syscalls on the FD, e.g. fstat, that
seemed like a bad idea.  Plus, the reason I was doing this was to tap a
Qlisten FD (don't open it, since that'd give us a new conversation).

Calling the device open may be slightly different than the Linux
implementation, but it appears necessary due the 9ns device model.  See
https://lwn.net/Articles/356029/ for a discussion (and note the flag
where FSs could request an open op for O_NODE).

Anyway, the basic infrastructure is in place for O_PATH calls.  Devices
can do something special if they want.  If they do nothing, O_PATH will
be set, and there will be no ACC_MODE flags set on the file/chan.  The
same goes for the VFS, but I don't plan to do anything special there.

If a device does something weird on an open, such as opening a clone in
 #I, you'll get a conversation back and a chan for the Qctl, but the FD
for that chan will have no read or write permissions.

Reinstall your kernel headers.
kern/include/ns.h
kern/include/ros/fs.h
kern/src/ns/sysfile.c
kern/src/syscall.c