Acessing kmem, how about a driver?

[BonnellDS]

<The problem's plain to see, too much technology>

     Seems to me that what people have been saying about a system call to
provide access to various system data structures could be handled very
effectively with a character device driver.

     The minor numbers for this driver would provide readonly access to
various areas, such as '/dev/proc' for the process table, '/dev/smap' for
the swap area map, '/dev/buf' for looking at the disk buffers, etc.

     Such a device driver would have the following benifits:

	1. Restricted access to memory, with useful error codes for anyone
	   trying to write to these read-only areas.

	2. Since the driver is a portion of the kernel, there is no
	   chance that the data reads will occur at the wrong address.

	3. Standard device names can be used, freeing applications code
	   from needing to 'nlist' a given kernel file (which may not even
	   be booted!).

	4. Such a driver could have it's own 'ioctl' commands. This feature
	   would allow an applications program to determine certain things
	   about a data area before the read occurs (such as the number and
	   size of 'proc' structures in '/dev/proc'). This way, the
	   applications code could notify the user that something is not
	   right, perhaps the applications code needs to be re-compiled.

     By using a driver, 'nlist' and 'lseek' are avoided, while data transfer
could be as great as, or greater than using a 'read' call, perhaps using
something similar to 'physio' (used in block device drivers)?

					Doug Bonnell
					AT&T ISL
					Denver, Colo.
					(303) 538-4762