(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 that it
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 should
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 and
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
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 follow
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 won't
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 won't be
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 that
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 pathname
