Re: Kernfs and Procfs

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sun, Sep 07, 2014 at 02:49:05PM -0500, Illinois Account wrote:
 > I was looking up into kernfs implementations, and I wanted to ask
 > you about what all other things should be added (what more
 > information should be available to user ?).

That isn't exactly clear -- the original idea of a procfs was to
support ps, and also to provide a cleaner way for a debugger to
inspect its target process (although this hasn't ever really panned
out very well...) but there's a lot of other material.

The matter of immediate interest is that anything that still has to be
gotten via libkvm and /dev/kmem should instead be made available via
procfs or kernfs (or sysctl, or more than one of these) but we don't
have very many such things left.

More broadly, any tool that gathers/reports kernel information that
isn't doing it via one of these common interfaces could stand to do
so; that includes a lot of *stat programs and also a variety of
device-specific and subsystem-specific *config programs.

For the time being I'd say it's more important to make it easy to
export data via a new kernfs/procfs/whatnot than to worry about
exactly what data there is to export. This means a minimum of code and
declarations to export things, and ways to add and remove entries (and
whole subtrees) as kernel objects come and go. 

 > Moreover, how should
 > ?sysctl? be integrated in this? (should it be somewhat similar to
 > ?sysfs' in Linux ?)

That isn't clear. I put some of my thoughts on the project page; I
built a research system some time ago where kernfs and sysctl were two
views on the same data. I don't think we can do this in NetBSD, as it
would require changing the schema for both sysctl and kernfs and break
compatibility, but we should still be looking at ways to integrate the
two systems.

At the consumer level (that is, in kernel code that wants to export
data) it should be possible to export each data item only once and
have it appear in whatever the proper place is in all of these
namespaces.

I don't think having a separate fs, mount point, and namespace for
sysctl makes a whole lot of sense. It developed that way in Linux
because they had implementation-levl problems in their procfs...

 > Also, could you comment on the formats of the virtual files.

Existing ones already have formats which have to be retained. New ones
should probably be similar, that is, tabular text.

The major difference between the Linux procfs and the original SVR4
procfs is that the Linux procfs contained text files; the SVR4 procfs
contained nodes that theoretically *were* processes but that you
couldn't do anything with except via custom ioctl() calls, and this
proved much less useful.

-- 
David A. Holland
dholland%netbsd.org@localhost