> Really?
>
> static int __emul_lookup_dentry(const char *name, struct nameidata *nd)
> {
> .
> if (path_walk(name, nd) == 0) {
> if (nd->dentry->d_inode) {
> dput(old_dentry);
> mntpu
ty den 09.08.2005 Klokka 22:42 (+0200) skreiv Miklos Szeredi:
> Trond, wake up! __emul_lookup_dentry() does nothing of the sort.
> Neither does anything else. In theory it could, but that's not a
> reason to do a confusing thing like that.
Really?
static int __emul_lookup_dentry(const char *na
> > > There is quite a bit of code out there that assumes it is free to stuff
> > > things into nd->mnt and nd->dentry. Some of it is Al Viro's code, some
> > > of it is from other people.
> > > For instance, the ESTALE handling will just save nd->mnt/nd->dentry
> > > before calling __link_path_wal
ty den 09.08.2005 Klokka 19:44 (+0200) skreiv Miklos Szeredi:
> > There is quite a bit of code out there that assumes it is free to stuff
> > things into nd->mnt and nd->dentry. Some of it is Al Viro's code, some
> > of it is from other people.
> > For instance, the ESTALE handling will just save
> > > > > + nd->intent.open.file = NULL;
> > > >
> > > > Why is this NULL assignment needed? nd will not be used after this.
> > > >
> > > > > + }
> > > > > + path_release(nd);
> > > > > +}
> > > > > +
> > > > >
> > >
> > > It could be dropped. The reason for putting it in
ty den 09.08.2005 Klokka 18:40 (+0200) skreiv Miklos Szeredi:
> > Intents are meant as optimisations, not replacements for existing
> > operations. I'm therefore not really comfortable about having them
> > return errors at all.
>
> In my case they are not an optimization, rather the only way to
>
> Intents are meant as optimisations, not replacements for existing
> operations. I'm therefore not really comfortable about having them
> return errors at all.
In my case they are not an optimization, rather the only way to
correctly perform an open with O_CREAT.
> > > + nd->intent.open.
>Have you looked at how we're dealing with this in NFSv4?
No.
--
Bryan Henderson IBM Almaden Research Center
San Jose CA Filesystems
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
ty den 09.08.2005 Klokka 08:47 (-0700) skreiv Bryan Henderson:
> >Intents are meant as optimisations, not replacements for existing
> >operations. I'm therefore not really comfortable about having them
> >return errors at all.
>
> That's true of normal intents, but not what are called intents here
>Intents are meant as optimisations, not replacements for existing
>operations. I'm therefore not really comfortable about having them
>return errors at all.
That's true of normal intents, but not what are called intents here. A
normal intent merely expresses an intent, and it can be totally ign
ty den 09.08.2005 Klokka 09:46 (+0200) skreiv Miklos Szeredi:
> > We've already got a patch that does this, and that I'm queueing up for
> > inclusion.
>
> Cool!
>
> > http://client.linux-nfs.org/Linux-2.6.x/2.6.12/linux-2.6.12-63-open_file_intents.dif
>
> Comments:
>
> > /*
> > + * Open inten
> We've already got a patch that does this, and that I'm queueing up for
> inclusion.
Cool!
> http://client.linux-nfs.org/Linux-2.6.x/2.6.12/linux-2.6.12-63-open_file_intents.dif
Comments:
> /*
> + * Open intents have to release any file pointer that was allocated
> + * but not used by the VFS
ty den 09.08.2005 Klokka 00:27 (+0200) skreiv Miklos Szeredi:
> I'd like to make my filesystem be able to do file creation and opening
> atomically. This is needed for filesystems which cannot separate
> checking open permission from the actual open operation.
>
> Usually any filesystem served fr
13 matches
Mail list logo
