The patch works, though. I'm seeing lots of function names in ksyms -a
and haven't done a single export_symbol in any module. Perhaps you mean
only in the kernel. Do I misunderstand?
} Hmm no, only functions that are explicitly exported through
} EXPORT_SYMBOL are given, they're the only one needed, if you were right
} the modules would be wasting an overkill of kernel not swappable ram for
} no good reason. This is true for both kernel and modules, no difference.
}
} And even if only the non static ones would not be given still it would
} be an high probability to need the system.map to resolve it.
That it certainly is!
} I appreciated it as a good start to get more reliable module reports,
} but I think it's not the best way to do it (but still it's way better
} than nothing! :).
Explaining to people what a System.map is, how to send it to me and trying
to get them to be methodical enough to be sure they're sending the right
one is a sure road to insanity. I took a daytrip down that road once.
} I'm not trying to make it easier, I'm trying to make it possible at all.
}
} Right now if I get an oops into a module from an user I cannot debug it
} period. I'm missing information that I cannot generate on my side. Every
} time he loads the module it will be at a different address (in
} particular with my tree where I try to allocate modules in multipages to
} get faster performance of the binary image at runtime even if they will
} use more ram), so unless he managed running ksymoops on the "after-oops"
} semi broken kernel, the oops will be totally useless.
It's hard in a cross-build environment to get ksymoops to be useful,
though. If you have suggestions, I have the will.
} Printing the start of each affected module into the oops will solve the
} problem and it will make possible for us to debug oopses that involves
} modules. Then to automate it we ""only"" need to teach ksymoops to
} parse those module-start informations.
-
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 : Tue Jul 30 2002 - 14:00:22 EST