site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Sep 3, 2009, at 3:14 AM, Nico Schmidt <lists@nschmidt.name> wrote: On 03.09.2009, at 05:11, Michael Smith wrote: On the subject of procfs; folks, you are trying to solve the wrong problem. Adding another access method absent a sensible schema does nothing to address the basic problem. How would you address the basic problem? I actually do not see a statement of the problem you are attempting to solve, beyond "I don't have an API for XYZ". Unless you have a specific, concrete application in mind for the API you are requesting, you are just asking people other than yourself to do work because you might need an API for XYZ some day. FWIW: My personal approach has always been to not need to ask the system for the information in the first place, because I already have it. The justification for a detailed synchronus arbitrary process status API that won't change for the next decade generally boils down to one of the following: (1) the information is for status reporting; solution: wrap a system utility like ps (2) the information is something the process being inspected wants published; solution: so have the process publish it, either procedurally via IPC or in /var/run (3) the information is something the parent wants published about one of its children; solution: the parent can publish it (see #2) (4) the information is something the parent needs later; solution: remember it, you're the one who started the process in the first place... you don't need an API just because you are too lazy to remember it (5) the information is not security sensitive, and some process would like to have it because it's overly nosy; solution: either quit being nosy or use a system tool (see #1), or use public self/parent published information if it exists (see #2) (6) the information is security sensitive, and some privileged process would like to have it because it's overly nosy (see #5; trust the tools to recognize privilege) (7) the information is security sensitive, and some unprivileged process would like to have it because it's overly nosy; solution: obtain privilege legitimately (see #6), or go away empty handed because leaving you empty handed was a design goal (behaves correctly) This email sent to site_archiver@lists.apple.com