On Tue, 20 Mar 2012 10:35:13 +0900 Julio Merino <[email protected]> wrote:
> Personally, I'd also like to see this project done. It was at one point > an idea I wanted to work on, but then lost the time to do so and > forgotten about it completely. I was initially reticent to reply to this thread at this time, because some details might be out of the scope of the GSoC project. But I think that those questions are important to consider in the design of a new procfs implementation, and the project description was very summary, so I decided to post them anyway: It was nice to be able to mount procfs with -o linux when I used Linux binary compatibility. Are there other scenarios where it is required? If not, should a new implementation simply be as compatible as possible with Linux, such that -o linux not be necessary? Even some supposedly portable software occasionally now expect a Linux-compatible procfs tree. Otherwise, I think that currently NetBSD doesn't make use of it, as kernfs and procfs are not mounted on my systems. Is there functionality that it should provide which sysctl/vmstat/pmap/fstat/drvctl don't? While on Linux it's used as a central repository for a lot of information, I regularily stumble on ad-hoc parsers in a number of applications that query from it, wondering why they didn't export that information via sysctl... If it should diverge from Linux and still support -o linux, is there a particular hierarchical direction it should respect, and suggested file format(s), i.e. plist is an example, which applications could parse using a supplied library? Or should the data be in a format designed for human reading only, with sysctl used for software? I doubt that a new implementation needs to remain compatible with the traditional 4.4BSD procfs hierarchy, as it's not really being used by software yet. I once thought that it might be useful to export procfs via NFS, but our current implementation doesn't support it. Is this something that a new implementation should allow? Thanks, -- Matt
