Re: [PATCH 0/4] Support for 'info proc' on FreeBSD cores and native

[Simon Marchi <simark@simark.ca>]

On 2017-12-22 05:05 PM, John Baldwin wrote:
> This series adds initial support for the 'info proc' command on
> FreeBSD native processes and process cores.  FreeBSD generally does
> not use the /proc filesystem, but instead exports data structures
> containing process information either via kernel system control nodes
> (for live processes), or in core dump notes.
> 
> My assumption is that the format of 'info proc' is expected to be
> somewhat OS-specific though probably not gratuitously so.
> 
> For 'info proc mappings' I choose to include both mapping attributes
> (such as permissions) along with the object file name.
> 
> I did choose to implement versions of 'info proc stat' and 'info proc
> status' that are similar to the output on Linux for now.  However,
> given that the output on FreeBSD is not tied to the output of files in
> /proc and that having both 'stat' and 'status' with overlapping
> content seems ambiguous, I do wonder if it wouldn't be better to just
> have a single command that includes one copy of the information (and
> perhaps treat 'stat' as an alias of 'status' on FreeBSD)?  I also
> noticed in the document that there are older commands such as 'info
> proc id' and 'info proc time' that if implemented would contain a
> subset of the info in the 'stat' commands.  I would possibly prefer to
> resurrect these commands on FreeBSD as subsets of 'stat/status'?  What
> do you all think?
> 
> I do eventually plan on adding a 'info proc files' that outputs a
> table of open file descriptors.
> 
> For the documentation I made minimal changes to the existing
> documentation for 'info proc' to not state that it requires /proc, but
> the wording could probably use improvement.  I have also not yet
> documented that FreeBSD supports 'proc stat' and 'proc status' due to
> the question above.

Hi John,

From reading the documentation, "info proc" seems to have been introduced
specifically to print things from /proc.  I find it too bad however that
the command line interface is based so closely on the /proc interface,
since it brings all of its quirks with it (e.g. stat vs status).  Also,
the important thing to the user is the information, regardless of where
it comes from.

With your patch, it moves "info proc" a little bit from "printing /proc"
to "print things about a process", which I think is totally fine.  I think
you could change the doc to put even less emphasis on the fact that the info
comes from /proc.

I'm fine with what you suggested above.

Simon