On Sun, 16 Jun 2002 Andries.Brouwer@cwi.nl wrote:
> First of all, _that_ is still recursive. And it's not easy to deal with -
> you need to release the object holding the link body (BTW, that can
> be almost anything - page, inode, kmalloc'ed area, vmalloc'ed area, etc.)
> after __vfs_follow_link() is done. And that means (at the very least)
> a stack of such objects, along with the information about their nature.
>
> Yes. But in the current tree only the cases page and kmalloc'ed area
> occur, and it is easy to transform the single occurrence of kmalloc'ed area
> (jffs2) into a use of page.
That's simply not true. Of the top of my head - /proc/self.
Look, it's getting ridiculous - you've already got a method that sometimes
follows link, sometimes leaves a bunch of stuff for callers to handle
(BTW, we'll have to duplicate that fun in another caller of ->follow_link()
and that, thanks to usual POSIX elegance, is already butt-ugly). You've
got (at the very least) 3 stacks of objects - dentry, link and page.
And that - saying "that happens to cover all current cases, except for one
but we can shoehorn it". Aside of the fact that statement is false,
you are making a lot of assumptions about what's natural for code - both
out-of-tree and in-tree (see above).
And then you'll need to shove said stacks into struct nameidata. Which
means either a static limit again or all sorts of fun with "allocate
externally if it gets bigger than...".
Face it, it _is_ ugly. Been there, done that - if you want to repeat
the exercise, more power to you, but it won't be any prettier.
Sure thing, everything is equivalent to Turing Machine and with sufficient
amount of brute force and kludges everything that can be done at all can be
done in any given way. In this particular case that amount will be
prohibitively painful. You don't believe me - try it yourself and see how
gross it will get...
-
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