Re: "Rewriting kernfs and procfs" - GSoC'12

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Tue, 20 Mar 2012 10:35:13 +0900
Julio Merino <jmmv%julipedia.org@localhost> 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