All of lore.kernel.org
 help / color / mirror / Atom feed
From: Demi Marie Obenour <demi@invisiblethingslab.com>
To: oss-security@lists.openwall.com
Cc: Alejandro Colomar <alx.manpages@gmail.com>,
	Michael Kerrisk <mtk.manpages@gmail.com>,
	linux-kernel@vger.kernel.org, linux-man@vger.kernel.org
Subject: Re: [oss-security] [patch] proc.5: tell how to parse /proc/*/stat correctly
Date: Wed, 28 Dec 2022 11:47:25 -0500	[thread overview]
Message-ID: <Y6xzIR9P+a6uaaEx@itl-email> (raw)
In-Reply-To: <20221228152458.6xyksrxunukjrtzx@mutt-hbsd>

[-- Attachment #1: Type: text/plain, Size: 1060 bytes --]

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.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2022-12-28 16:53 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-22 16:42 [patch] proc.5: tell how to parse /proc/*/stat correctly Alexey Dobriyan
2022-12-22 22:03 ` [oss-security] " Dominique Martinet
2022-12-22 23:21   ` Solar Designer
2022-12-23  0:15     ` Dominique Martinet
2022-12-23  0:21   ` Jan Engelhardt
2022-12-28  0:44   ` Lyndon Nerenberg (VE7TFX/VE6BBM)
2022-12-28  1:50     ` Tavis Ormandy
2022-12-28  1:50       ` Tavis Ormandy
2022-12-30 20:15       ` Jakub Wilk
2022-12-28 15:24     ` Shawn Webb
2022-12-28 15:31       ` Shawn Webb
2022-12-28 16:47       ` Demi Marie Obenour [this message]
2022-12-28 17:09         ` Jan Engelhardt
2022-12-28 17:25         ` Shawn Webb
2022-12-28 18:02           ` Demi Marie Obenour
2022-12-28 18:36             ` John Helmert III
2022-12-28 19:24             ` Shawn Webb
2022-12-28 19:57               ` Alejandro Colomar
2022-12-28 22:14             ` Theodore Ts'o
2022-12-29  0:33               ` Demi Marie Obenour
2022-12-31 16:31       ` David Laight
2022-12-31 17:27         ` Solar Designer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y6xzIR9P+a6uaaEx@itl-email \
    --to=demi@invisiblethingslab.com \
    --cc=alx.manpages@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=oss-security@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.