On Feb 10, 2012, at 11:49 PM, Mouse wrote:
Why not use O_DIRECTORY (which is part of -current) and add that to
flags?
Backporting that might be a better alternative. What are its
semantics?
It means the open will only succeed is the file is a directory.
Why not use O_DIRECTORY (which is part of -current) and add that to
flags?
Backporting that might be a better alternative. What are its
semantics?
It means the open will only succeed is the file is a directory.
Worth having, but not sufficient by itself, because it still requires
something
On Feb 11, 2012, at 12:31 AM, Mouse wrote:
Why not use O_DIRECTORY (which is part of -current) and add that to
flags?
Backporting that might be a better alternative. What are its
semantics?
It means the open will only succeed is the file is a directory.
Worth having, but not sufficient
Right. You add O_DIRECTORY to that check.
Ah, I misunderstood. My apologies.
if ((flags (FREAD|FWRITE)) == 0 (flags O_DIRECTORY) == 0)
return EINVAL;
if ((flags O_DIRECTORY) != 0 (flags (FREAD|FWRITE)) != 0)
return EINVAL;
Actually, what I have now skips the latter of
On Feb 11, 2012, at 2:04 AM, Mouse wrote:
I find myself wanting something I'm tentatively calling O_NOACCESS,
which is basically open for neither read nor write. (I want this
mostly so I can open a --x directory for fchdir() purposes.)
Looking at sys_open(), I see that one of the first
On Sat, Feb 11, 2012 at 02:04:23AM -0500, Mouse wrote:
I find myself wanting something I'm tentatively calling O_NOACCESS,
which is basically open for neither read nor write. (I want this
mostly so I can open a --x directory for fchdir() purposes.)
Looking at sys_open(), I see that one of
On Sat, Feb 11, 2012 at 10:27:42PM +, David Laight wrote:
On Sat, Feb 11, 2012 at 02:04:23AM -0500, Mouse wrote:
I find myself wanting something I'm tentatively calling O_NOACCESS,
which is basically open for neither read nor write. (I want this
mostly so I can open a --x directory
There is no problem. O_NOACCESS would be 3. When converted from O_*
to F* it becomes 0.
And that is indeed what I did. FFLAGS() and OFLAGS() become more
complex than just adding and subtracting 1, but that's not difficult to
deal with. (If anyone's curious exactly what I did, look at the
There are, however, at least three possible things there's currently
no open flags for.
(1) search/lookup on a directory, as described;
(2) execute on an (executable) regular file;
(3) really nothing at all.
#1 and #2 could be legitimately combined (as the --x permission
setting is
On Sat, Feb 11, 2012 at 07:12:32PM -0500, Mouse wrote:
(Note that while there may be no use for #2 in userlevel code, unless
perhaps if we add an fexecve() call, having it would be convenient in
the kernel.)
fexecve() makes a lot of sense too. So would an flink(), and indeed f*
One of the benefits of userland filesystems is that a bug in a
filesystem will just crash the filesystem, not the whole kernel. But a
crashed filesystem causes an unmount, and leaves the system non fully
functionnal.
I thought that we could respawn a crashed userland filesystem, lookup
all active
Of course the feature would be broken in some cases, but we could
make the thing optional using a vfs.puffs.respawn sysctl, which would
contain a colon-separated mount points subjected to respawn.
What happens if a mount point contains a colon?
More to the point, I think this puts the
On Sun, 12 Feb 2012 01:02:38 -0500 (EST)
Mouse mo...@rodents-montreal.org wrote:
Of course the feature would be broken in some cases, but we could
make the thing optional using a vfs.puffs.respawn sysctl, which would
contain a colon-separated mount points subjected to respawn.
What
Mouse mo...@rodents-montreal.org wrote:
Of course the feature would be broken in some cases, but we could
make the thing optional using a vfs.puffs.respawn sysctl, which would
contain a colon-separated mount points subjected to respawn.
What happens if a mount point contains a colon?
Is there any way it could be set as an option at mount time?
The problem is that mount(8) passes the options verbatim to
/sbin/mount_xxx, which is supposed to start the xxx filesystem. The
filesystem will parse the options on its own before passing
appropriate flags to mount(2). We have no
On Sun, Feb 12, 2012 at 07:12:25AM +0100, Emmanuel Dreyfus wrote:
One of the benefits of userland filesystems is that a bug in a
filesystem will just crash the filesystem, not the whole kernel. But a
crashed filesystem causes an unmount, and leaves the system non fully
functionnal.
I
16 matches
Mail list logo
