oss-sec mailing list archives

Re: [patch] proc.5: tell how to parse /proc/*/stat correctly


From: Demi Marie Obenour <demi () invisiblethingslab com>
Date: Wed, 28 Dec 2022 13:02:35 -0500

On Wed, Dec 28, 2022 at 12:25:17PM -0500, Shawn Webb wrote:
On Wed, Dec 28, 2022 at 11:47:25AM -0500, Demi Marie Obenour wrote:
On Wed, Dec 28, 2022 at 10:24:58AM -0500, Shawn Webb wrote:
On Tue, Dec 27, 2022 at 04:44:49PM -0800, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
Dominique Martinet writes:

But, really, I just don't see how this can practically be said to be parsable...

In its current form it never will be.  The solution is to place
this variable-length field last.  Then you can "cut -d ' ' -f 51-"
to get the command+args part (assuming I counted all those fields
correctly ...)

Of course, this breaks backwards compatability.

It would also break forwards compatibility in the case new fields
needed to be added.

The only solution would be a libxo-style feature wherein a
machine-parseable format is exposed by virtue of a file extension.

Examples:

1. /proc/pid/stats.json
2. /proc/pid/stats.xml
3. /proc/pid/stats.yaml_shouldnt_be_a_thing

A binary format would be even better.  No risk of ambiguity.

I think the argument I'm trying to make is to be flexible in
implementation, allowing for future needs and wants--that is "future
proofing".

Linux should not have an XML, JSON, or YAML serializer.  Linux already
does way too much; let’s not add one more thing to the list.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

Attachment: signature.asc
Description:


Current thread: