Re: [PATCH 0/2] Report the size of pages backing VMAs in /proc V3

["Albert Cahalan" <acahalan@gmail.com>]

Adding " (hpagesize=4096kB)" onto the end of a filename is as vile
as adding " (deleted)" onto the end. If anything is going to change
in this area, it should be the elimination of " (deleted)". These
tags are perfectly legitimate in filenames.

Looping on stat() while chopping off suspected tags is dreadful.
Besides just being gross, it's slow.

gdb will tolerate up to 7 flags, procps will tolerate up to 31 flags,
and both will tolerate anything without a '/' before the filename.

Obviously, every author of a /proc-based tool has been forced to
take a random guess at the ABI. The /proc/*/smaps is so gross and
that I put off writing a parser for years.

What you can probably get away with:

After the "rwxp" stuff you can add 3 more flags. (gdb limit)
You could use 'L' for locked pages, 'R' for swap reservation,
and 'D' for deleted files. It's probably much better to save
space though, since gdb will crash if you add too many flags.
Three characters can be 18 bits if you base-64 encode them,
being careful to avoid the '/' character. (adding 0x30 works)

Right before the filename, you can add anything except a '/'.
You could add a few columns of numbers or a second flags field.

Not that it matters on such a slow-ass file format, but you
can make parsing faster if you encode the page size in one byte.
Simply add 0x30 to the page shift, then print that byte. Note that
this would let you cram the page size into the flags field.

BTW, I'm thinking that the /proc/*/*maps files fail when the
lines exceed 4096 bytes. The pathname may legitimately be that
long, plus it can be backslash escaped, plus there is all the
junk on the beginning.