Hi Jan,
How stable do you think kernel function names are (or guaranteed to be)?
Are there really scripts grepping for functions names which rely on the
absence of a prefix?
I think in this instance the need for backward compatibility is unwarranted.
Regards,
Jim
On 11/04/2016 08:58 AM, Jan Rybar wrote:
Hello Jim,
yes, I like the idea of throwing it all away, but I need to keep in mind
the backward support across the distros and all users with their scripts
depending on it.
If you agree, I would make it like you propose in newlib, where other
major changes happen. Let's get rid of this in future.
On 11/04/2016 02:39 PM, Jim Warner wrote:
On 11/03/2016 09:52 AM, Jan Rybar wrote:
I created new merge request with new ps option which I believe is
needed. Can you please take a look at it?
https://gitlab.com/procps-ng/procps/merge_requests/30
If you agree, I will hand over the newlib patch after monday (if
needed).
Note: Using new external symbol is a way to not change API, which is
IMHO preferable in this case.
Hi Jan,
Must everything be over-engineered?
Why not go with a simple approach like the following?
Regards,
Jim
diff --git a/proc/wchan.c b/proc/wchan.c
index b4e40fe..eb820e8 100644
--- a/proc/wchan.c
+++ b/proc/wchan.c
@@ -46,11 +46,8 @@ const char * lookup_wchan (int pid) {
// lame ppc64 has a '.' in front of every name
if (*ret=='.') ret++;
- switch (*ret){
- case 's': if(!strncmp(ret, "sys_", 4)) ret += 4; break;
- case 'd': if(!strncmp(ret, "do_", 3)) ret += 3; break;
- case '_': while(*ret=='_') ret++; break;
- default : break;
- }
+ // whacked switch statement leftover, keep 'do_' or 'sys_' prefix
+ if (*ret=='_') ret++;
+
return ret;
}
