Messages in this thread Patch in this message |  | | Date | Mon, 17 Sep 2001 16:51:11 -0700 | From | David Mosberger <> | Subject | __emul_prefix() problem |
| |
I have been toying with __emul_prefix() on ia64 linux as a means to deal with x86 programs that use absolute paths when loading shared objects (such as PAM or the GTK themes). This works quite well, but it breaks the traditional UNIX way of translating a relative path into an absolute path. The OpenOffice installer does this, for example. What happens precisely is that the installer attempts to create an absolute path by stat()ing "/." and then walking the parent directory chain until it finds the directory entry with a matching i-node number. This doesn't work because if an x86 binary stat()s this path, it will get the i-node number of /emul/ia32-linux/ (in the ia64 linux case) and things quickly go downhill from there.
I'm not sure there is a clean fix to this, but one proposal is attached below: it causes __emul_lookup_dentry() to ignore the alternate root for paths that resolve to a directory. This obviously could create other problems, but I suspect there is no solution that works 100% in all cases (the fundamental being that we now have two different root nodes...).
Comments?
--david
PS: I cc'd all the platform maintainers that use a non-NULL emul_prefix, except for Dave Miller who in private mail indicated that he doesn't care about this problem
--- fs/namei.c~ Sat Jul 21 20:20:40 2001 +++ fs/namei.c Mon Sep 17 15:10:20 2001 @@ -604,10 +604,14 @@ static int __emul_lookup_dentry(const char *name, struct nameidata *nd) { if (path_walk(name, nd)) - return 0; + return 0; /* something went wrong... */ - if (!nd->dentry->d_inode) { + if (!nd->dentry->d_inode || S_ISDIR(nd->dentry->d_inode->i_mode)) { struct nameidata nd_root; + /* + * NAME was not found in alternate root or it's a directory. Try to find + * it in the normal root: + */ nd_root.last_type = LAST_ROOT; nd_root.flags = nd->flags; read_lock(¤t->fs->lock); - 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/
|  |