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 Tue, Nov 23, 2010 at 06:49:47PM +0200, Antti Kantee wrote:
> On Fri Nov 19 2010 at 00:11:12 +, Andrew Doran wrote:
> > You can release it with either call, mutex_spin_ is just a way to avoid
> > additional atomic operations. The ususal case is adaptive mutex, but
> > stuff like the dispatch
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 13:05:33 -0500, Thor Lancelot Simon wrote:
> On Wed, Nov 24, 2010 at 07:56:33PM +0200, Antti Kantee wrote:
> >
> > Dunno about NetBSD specifically, but this suggests great differences:
> > http://www.netbsd.org/~ad/50/img15.html
>
> The problem is that it demonstrates that N
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
On Wed, Nov 24, 2010 at 07:56:33PM +0200, Antti Kantee wrote:
>
> Dunno about NetBSD specifically, but this suggests great differences:
> http://www.netbsd.org/~ad/50/img15.html
The problem is that it demonstrates that NetBSD's better *on that hardware*
than it was. There are confounding variabl
On Wed Nov 24 2010 at 12:42:44 -0500, Thor Lancelot Simon wrote:
> On Wed, Nov 24, 2010 at 04:52:38PM +0200, Antti Kantee wrote:
> > Thanks, I'll use your list as a starting point. One question though:
> >
> > On Wed Nov 24 2010 at 00:16:37 +, Andrew Doran wrote:
> > > - build.sh on a static,
On Wed, Nov 24, 2010 at 04:52:38PM +0200, Antti Kantee wrote:
> Thanks, I'll use your list as a starting point. One question though:
>
> On Wed Nov 24 2010 at 00:16:37 +, Andrew Doran wrote:
> > - build.sh on a static, unchanging source tree.
>
> >From the SSP discussion I have a recollectio
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
>
Thanks, I'll use your list as a starting point. One question though:
On Wed Nov 24 2010 at 00:16:37 +, Andrew Doran wrote:
> - build.sh on a static, unchanging source tree.
>From the SSP discussion I have a recollection that build.sh can be
very jittery, up to the order of 1% per build. I'v
> 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 Mon, Nov 22, 2010 at 02:52:45PM +, Andrew Doran wrote:
>
> It wants for per-CPU buffers that get merged when the data is read out..
We're doing that now. We will doubtless scream for help if it's not
sufficient to fix the issue (in the course of looking into this various
design and implem
18 matches
Mail list logo
