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 [email protected]
