> > What I'm saying is that read and write are _no_more_ related to the
> > file than fstat. Read/write operate on inode data, fstat operates on
> > inode metadata.
>
> The read and write operations are DEFINITELY related to the file descriptor
> because of f_pos. Each process opening the same f
On Sep 21, 2007 16:59 +0200, Miklos Szeredi wrote:
> What I'm saying is that read and write are _no_more_ related to the
> file than fstat. Read/write operate on inode data, fstat operates on
> inode metadata.
The read and write operations are DEFINITELY related to the file descriptor
because of
On Sep 21, 2007 14:23 +0200, Miklos Szeredi wrote:
> @@ -1214,10 +1214,12 @@ struct inode_operations {
> + int (*setxattr) (struct dentry *, const char *,const void *,size_t,int,
> + struct file *);
> + ssize_t (*getxattr) (struct dentry *, const char *, void *, size_t
> On Fri, Sep 21, 2007 at 10:32:31AM -0400, Trond Myklebust wrote:
> > On Fri, 2007-09-21 at 15:16 +0200, Miklos Szeredi wrote:
> >
> > > > ftruncate is a special case due to O_TRUNC.
> > >
> > > No, it's special, because it does not do permission checking, while
> > > truncate() does.
> >
> > S
> > > ftruncate is a special case due to O_TRUNC.
> >
> > No, it's special, because it does not do permission checking, while
> > truncate() does.
>
> So why not just add file->f_op->ftruncate() and file->f_op->fstat()?
Sure, we could add those.
I'm not sure it's worth adding new file operation
On Fri, Sep 21, 2007 at 10:32:31AM -0400, Trond Myklebust wrote:
> On Fri, 2007-09-21 at 15:16 +0200, Miklos Szeredi wrote:
>
> > > ftruncate is a special case due to O_TRUNC.
> >
> > No, it's special, because it does not do permission checking, while
> > truncate() does.
>
> So why not just add
On Fri, 2007-09-21 at 15:16 +0200, Miklos Szeredi wrote:
> > ftruncate is a special case due to O_TRUNC.
>
> No, it's special, because it does not do permission checking, while
> truncate() does.
So why not just add file->f_op->ftruncate() and file->f_op->fstat()?
Most filesystems can trivially
> > I don't think it's silly. Read/write get passed the file descriptor,
> > and it makes a lot of sense, if the filesystem has stateful opens.
> >
> > Similarly for any fs operation that gets a file descriptor, it makes
> > sense to pass the relevant open file down into the filesystem.
>
> read
On Fri, Sep 21, 2007 at 03:00:06PM +0200, Miklos Szeredi wrote:
> I don't think it's silly. Read/write get passed the file descriptor,
> and it makes a lot of sense, if the filesystem has stateful opens.
>
> Similarly for any fs operation that gets a file descriptor, it makes
> sense to pass the
> On Fri, Sep 21, 2007 at 02:23:46PM +0200, Miklos Szeredi wrote:
> > From: Miklos Szeredi <[EMAIL PROTECTED]>
> >
> > Pass the open file into the filesystem's *xattr() methods.
> >
> > This is needed to be able to correctly implement open-unlink-f*xattr
> > semantics, without having to resort to
On Fri, Sep 21, 2007 at 02:23:46PM +0200, Miklos Szeredi wrote:
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Pass the open file into the filesystem's *xattr() methods.
>
> This is needed to be able to correctly implement open-unlink-f*xattr
> semantics, without having to resort to "silly-renami
11 matches
Mail list logo
