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.
>
>> 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
Mouse 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?
Then you have serious
On Sun, 12 Feb 2012 01:02:38 -0500 (EST)
Mouse 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
> 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 infor
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
>> fexecve() makes a lot of sense too. So would an flink(), [...]
> We'd want to be a bit careful about adding these as there are
> permission checks that are implied by specifying a path which you do
> not get with the f* calls mentioned.
Not per se, but the fd on the directory proxies for them,
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*
> 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
> 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 t
On Sat, Feb 11, 2012 at 05:02:27PM -0500, Steven Bellovin wrote:
> The fine details (per later messages in the thread) are very important
> and do need to be resolved. That said, there's a strong philosophical
> case for something like this (but perhaps not exactly this) to exist,
> in that we
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 d
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 on
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 fi
While working on another problem, I've noticed that rescanning an i2c
bus (such as when loading an i2c device's driver module) cause an awful
lot of redundant calls to driver *_match() funtion. In particular, when
the spdmem(4) driver with its 8 possible attachments is loaded, each
possible spd
> 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
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, bu
>>> 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
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.
19 matches
Mail list logo