On Mon, 17 Jun 2002 Andries.Brouwer@cwi.nl wrote:
> >> The result of Step One is that the loop no longer touches all
> >> filesystems but lives entirely in namei.c. So, the second patch,
> >> that only changes namei.c can change the recursion into iteration.
> >> Maybe tomorrow or the day after.
>
> > Obvious breakage: nd->flags can be clobbered by __vfs_follow_link(),
> > so your do_follow_link() and friends are broken.
>
> Yes, I know. No doubt you are able to fix that by reading that bit
> before calling __vfs_follow_link(). It will be repaired fully
> automatically tomorrow or the day after when __vfs_follow_link()
> disappears altogether.
>
> But that is the microscopic criticism. I was more interested in
> hearing comments on the global setup.
I don't see global setup here - just a (rather messy) change of API.
The really interesting question is how you'll handle namei.c code.
Bringing the call of __vfs_follow_link() into do_follow_link() is
not interesting in itself - you still have recursion to eliminate and
that's where the hell will begin. Change of ->follow_link() prototype
per se doesn't buy anything and is as you admit kludgy. If you need
it for really interesting stuff - please do show that stuff.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jun 23 2002 - 22:00:11 EST