[procps] Re: Is skill not doing signals lists correctly?
- From: Craig Small <csmall-procps@xxxxxxxxxx>
- To: procps@xxxxxxxxxxxxx
- Date: Thu, 12 Sep 2013 06:52:10 +1000
On Wed, Sep 11, 2013 at 02:56:10PM -0500, Jim Warner wrote:
> I trust you're talking about just the two print_signals functions. If
> so, keep in mind that while only our skill uses them other programs may
> too. I don't think now is the proper time to break the API/ABI in that
> way.
You mean programs outside procps? No other program in procps uses it.
I'll do some more checks but if I don't find anything else that does use
them, it doesn't make sense to have them in the library for one program
to use.
> > killall does it differently. I think its more correct but not 100% sure,
> > it walks the structure.
>
> Personally, I don't care for the your killall approach and the whims of a
> particular <signals.h> implementation.
OK, that's the back-end part. I often thought it was odd too. But I
think skill does it wrong. It mixes the placement of a signal in an
array with the signal number and these are different.
> Merge request #13 (namespaces) broke 'make dist'. The attached
> patch should fix it.
Ah yes, add a file to dist. All apply that this morning.
> Merge request #2 (uptime) should serve as an example of how NOT to
> alter the library in the future. Instead of limiting impact to only the
> library and uptime by exporting one new function, an existing API was
> changed (sprint_uptime) thus necessitating changes to top and w in
> addition to the library and uptime.
I agreee generally that the API should be changed minimally, the problem
is that the current API is not very good or clean. The general idea of
not changing it for change sake is important though.
- Craig
--
Craig Small VK2XLZ http://enc.com.au/ 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:
