On Wed, Nov 24, 2010 at 08:30:18PM +0200, Antti Kantee wrote:
> > I think it makes more sense for doregister to check for at least one
> > leading '/' and remove the leading slashes before storing the key.
> > Then the key will match the name passed by lookup; otherwise the
> > leading slash wo
On Wed, Nov 24, 2010 at 01:26:04PM -0500, der Mouse wrote:
> > Right. But if you want a guaranteed absolute path you should be able
> > to do it by calling getcwd first.
>
> Only if you accept breakage if the current directory no longer has any
> name.
Well, if you can't call getcwd, then it
On Wed Nov 24 2010 at 18:12:00 +, David Holland wrote:
> > As for etfs, as you might be able to see from the code, it's only used
> > for root vnode lookups. I cannot think of a reason why we cannot define
> > the key to start with exactly one leading '/'. Some in-tree users may
> > not f
> Right. But if you want a guaranteed absolute path you should be able
> to do it by calling getcwd first.
Only if you accept breakage if the current directory no longer has any
name.
Of course, if you consider that acceptable, then fine. I don't, not
for something as central as namei (though th
On Wed, Nov 24, 2010 at 06:19:50PM +, David Laight wrote:
> > First, background: VOP_LOOKUP is the per-fs vnode operation that takes
> > a directory and a name and returns the vnode associated with that
> > name. This currently has a horrific interface and the chief goal of
> > the namei cl
On Tue, Nov 23, 2010 at 11:13:02PM +, David Holland wrote:
> I have run into a problem fixing namei.
>
> First, background: VOP_LOOKUP is the per-fs vnode operation that takes
> a directory and a name and returns the vnode associated with that
> name. This currently has a horrific interface an
On Wed, Nov 24, 2010 at 07:32:42PM +0200, Antti Kantee wrote:
> > Furthermore, it is just plain gross for the behavior of VOP_LOOKUP in
> > some directory to depend on how one got to that directory. As a matter
> > of design, the working path should not be available to VOP_LOOKUP and
> > VOP_LO
Hi,
On Tue Nov 23 2010 at 23:13:02 +, David Holland wrote:
> Furthermore, it is just plain gross for the behavior of VOP_LOOKUP in
> some directory to depend on how one got to that directory. As a matter
> of design, the working path should not be available to VOP_LOOKUP and
> VOP_LOOKUP shoul
>>> (Note that this is free -- it would require splicing a getcwd into
>>> every namei call.)
>> _Not_ free, I assume you mean?
> er right, silly editor... :-/
:-รพ I've had that happen to me often enough.
> Anyway, it looks as if it's not needed.
Just as well. It has (since) occurred to me tha
On Wed, Nov 24, 2010 at 08:26:42AM -0500, der Mouse wrote:
> > (2) does anyone think that a correct namei design should provide a
> > correct canonicalized full pathname for its inspection during lookup?
>
> Not me.
>
> > (Note that this is free -- it would require splicing a getcwd into
>
> However, I discovered today that rumpfs's VOP_LOOKUP implementation
> relies on being able to access not just the name to be looked up, but
> also the rest of the pathname namei is working on, specifically
> including the parts that have already been translated.
"Eww." The rest of the path to t
On Nov,Wednesday 24 2010, at 5:35 AM, David Holland wrote:
> On Tue, Nov 23, 2010 at 11:13:02PM +, David Holland wrote:
>> However, I discovered today that rumpfs's VOP_LOOKUP implementation
>> relies on being able to access not just the name to be looked up, but
>> also the rest of the pathn
On Tue, Nov 23, 2010 at 11:13:02PM +, David Holland wrote:
> However, I discovered today that rumpfs's VOP_LOOKUP implementation
> relies on being able to access not just the name to be looked up, but
> also the rest of the pathname namei is working on, specifically
> including the parts th
I have run into a problem fixing namei.
First, background: VOP_LOOKUP is the per-fs vnode operation that takes
a directory and a name and returns the vnode associated with that
name. This currently has a horrific interface and the chief goal of
the namei cleanup is to rectify this so all it needs
14 matches
Mail list logo