public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Enrico Weigelt <weigelt@metux.de>
To: linux kernel list <linux-kernel@vger.kernel.org>
Subject: Re: VFS + path walktrough
Date: Mon, 5 May 2008 15:43:15 +0200	[thread overview]
Message-ID: <20080505134315.GF32019@nibiru.local> (raw)
In-Reply-To: <20080505131307.GM5882@ZenIV.linux.org.uk>

* Al Viro <viro@ZenIV.linux.org.uk> wrote:
> On Mon, May 05, 2008 at 03:06:23PM +0200, Enrico Weigelt wrote:
> 
> > We could just add another call vector to struct file_operations,
> > as replacement for link_path_walk() - if it's zero, the original
> > function is used. This way an filesystem can do the walktrough
> > by it's own, but doesn't need to.
> > 
> > 
> > What do you think about this ?
> 
> That you have quite forgotten about mounts.  

hmm, I though this would be done before the link_path_walk() 
call happens ;-o

> And we *REALLY* don't want to shift the entire logics of 
> link_path_walk() into filesystems - this is insane. 

Only for those filesystems who *really* want to do it by 
themselves and set the appropriate call vector. All other 
fs'es will just leave it blank (even don't have to be touched)
and so the old way remains for them.

To get around mointpoint issues, we could at least do it only
when an special mount option is given and add an big-fat warning
that mountpoints within these mounts won't work. So these fast
lookups will only happen when:

#1: the fs explicitly supports it
#2: mounted with an special option

And if you use that option, you'll simply loose the ability
of using mointpoints within this specific mount. This won't 
affect any situation other than #1 && #2, IMHO this is better
than no chance of fast lookups at all. Of course, an cleaner
approach would be better, but it's IMHO not critical.

BTW: there are (or have been) certain speed improvements for 
specific situations w/ loosing other standard features, eg.
fast bridging.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------

  reply	other threads:[~2008-05-05 13:43 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-05 12:40 VFS + path walktrough Enrico Weigelt
2008-05-05 13:06 ` Enrico Weigelt
2008-05-05 13:13   ` Al Viro
2008-05-05 13:43     ` Enrico Weigelt [this message]
2008-05-05 15:35       ` Al Viro
2008-05-05 16:43         ` Miklos Szeredi
2008-05-05 17:03           ` Miklos Szeredi
2008-05-05 17:14           ` Al Viro
2008-05-05 17:33             ` Miklos Szeredi
2008-05-05 17:40               ` Al Viro
2008-05-05 18:03                 ` Miklos Szeredi
2008-05-05 18:31                   ` Miklos Szeredi
2008-05-05 20:16                     ` Trond Myklebust
2008-05-05 20:35                       ` Miklos Szeredi
2008-05-05 18:50                   ` Enrico Weigelt
2008-05-05 18:23                 ` Enrico Weigelt
2008-05-05 18:34                   ` Al Viro
2008-05-05 19:02                     ` Enrico Weigelt
2008-05-05 19:09                       ` Al Viro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080505134315.GF32019@nibiru.local \
    --to=weigelt@metux.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox