>> 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.
Andries
On Mon, 17 Jun 2002 [email protected] 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.