Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site druky.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxj!houxm!ihnp4!drutx!druky!egz From: egz@druky.UUCP (BonnellDS) Newsgroups: net.unix-wizards Subject: Acessing kmem, how about a driver? Message-ID: <813@druky.UUCP> Date: Mon, 10-Dec-84 11:50:22 EST Article-I.D.: druky.813 Posted: Mon Dec 10 11:50:22 1984 Date-Received: Tue, 11-Dec-84 03:34:17 EST Organization: AT&T Information Systems Laboratories, Denver Lines: 39Seems 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