[procps] Re: ps - wchanf option
- From: Craig Small <csmall@xxxxxxxxxx>
- To: Jim Warner <james.warner@xxxxxxxxxxx>, Jan Rybar <jrybar@xxxxxxxxxx>, procps@xxxxxxxxxxxxx
- Date: Fri, 04 Nov 2016 22:53:29 +0000
On Sat, Nov 5, 2016 at 1:25 AM Jim Warner <james.warner@xxxxxxxxxxx> wrote:
I have no idea why Albert took that approach. Perhaps it had to do with
field widths.
But nowadays, those kernel function names can be quite long.
And on my laptop I see no 'sys_' prefixes and only one 'do_wait' (so far).
These are pretty ancient things. I suspect the reasons would be hard to
determine.
procps version 1.12.2 way back in October 1997 had it filtering sys_ but
not do_ I cannot really go back any further than that.
I cannot find exactly where the do_ filtering came in but it was not there
in 1.2.2 but was there in version 2.07 which is the oldest version we have
in GitLab. Unfortunately Albert didn't use to use a VCS, or at least a
public one so the earliest import of ksym.c which I did in 2002 already has
this.
I seem to recall one of them had something to do with module kernel
symbols, I think it was the do_ prefix was used for modules and sys_ for
kernel proper.
So why the filtering? It has been many years since this was discussed but
it was something like:
All (or most) kernel calls used to have an internal name of do_foo or
sys_foo while the system call the programmer used didn't have the prefix.
So take nanosleep for an example. You would use this in your program but if
you looked at the wchan column that never appears (its not a kernel symbol)
but sys_nanosleep and do_nanosleep are kernel symbols. I believe it was
done to make the connection easier between the two.
In theory everything in the kernel was sys_* or do_* and everything else
outside it was not those prefixes.
I'm not sure how much of a problem it is. I just read the bug report at
https://bugzilla.redhat.com/show_bug.cgi?id=1322111
Now, isn't this a case of someone not understanding what wchan is?
The definition of wchan is the *kernel* function where the process is
sleeping.
Where does get_write_access live? I'd look myself but of course redhat
hides their bugs so I cannot see them. It implies that the kernel has both
"do_get_write_access" and "sys_get_write_access" and "get_write_access"
which seems a totally bad idea.
- Craig
--
Craig Small (@smallsees)
http://dropbear.xyz/ csmall at : enc.com.au
Debian GNU/Linux
http://www.debian.org/ csmall at : debian.org
GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
Other related posts:
