Paul Fox wrote: > ralf wrote: > > > > Also, I don't see why insmod should need the realpath of the object. I > > thought the basename of the object file is used as the module name, but > > I have also seen few cases where the module name was not the file name, > > so that seems to be only a convention and not mandatory. > > so you're saying the current code in insmod.c, and even a change to > use the _follow() version of readlink, would be okay, right? just making > sure i understand you. :-) > No, I didn't at all look at the insmod code. Actually this seems to refer to the code for 2.4 kernels, and I haven't used 2.4 kernels for some time. As realpath was used in add_ksymoops_symbols, I suppose ksymoops might also work with the unmodified filename, as the kernel would follow the same symlinks and eventually arrive at the same file. But I don't know and I don't have a kernel 2.4 or the utilities for the older kernels to try it.
> > I noticed that you test against MAXSYMLINKS only in the case of relative > > symlinks. I consider this inconsistent. > > oops, you're right. that's an oversight, which i'll fix. (note > that the test isn't really guaranteed -- there may be more > undetected symlinks embedded in the middle of the path, since i'm > only checking the tail. but it will be caught eventually.) > symlinks in the path may cause ELOOP in readlink. That should be no problem, the final path would case ELOOP anyway. Regards Ralf Friedl _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
