Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site rlgvax.UUCP Path: utzoo!watmath!clyde!cbosgd!ihnp4!zehntel!dual!qantel!intelca!hplabs!hao!seismo!rlgvax!guy From: guy@rlgvax.UUCP (Guy Harris) Newsgroups: net.unix-wizards Subject: Re: Acessing kmem, how about a driver? Message-ID: <295@rlgvax.UUCP> Date: Tue, 11-Dec-84 18:29:38 EST Article-I.D.: rlgvax.295 Posted: Tue Dec 11 18:29:38 1984 Date-Received: Sat, 15-Dec-84 00:12:42 EST References: <813@druky.UUCP> Organization: CCI Office Systems Group, Reston, VA Lines: 63 > 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. This can be achieved, in large part, by having "/dev/kmem" only writable by the super-user, and readable by group "0", and by having all programs that only need to read the data be set-GID 0 rather than set-UID 0. (While we're on the topic of group "0", I've found that a lot of programs are set-UID solely because they need to be able to *read* arbitrary files; would giving "sub-super-user" privileges to gid 0, i.e., the ability to open arbitrary files for reading, be useful?) > 2. Since the driver is a portion of the kernel, there is no > chance that the data reads will occur at the wrong address. Well, if you got the right name list, this shouldn't happen anyway. It can happen if the table you're reading has pointers to other structures, and those other structures move or change between reading the table entry and the other structure in question, but fixing that would require a driver which knew about those pointers and made reading the table entry and what that entry points to an atomic operation. > 3. Standard device names can be used, freeing applications code > from needing to 'nlist' a given kernel file (which may not even > be booted!). Unfortunately, a complete solution to this problem requires that you provide a driver for every piece of data in the kernel that any program would like to read. There are a lot of programs in 4.2BSD that rummage around the kernel ({io,vm,net}stat, just to name three) and they look at a lot of data structures; it could be hard to anticipate all the needed data structures. It might solve part of the problem ("ps", for instance), but any "complete" solution will break when the next program is written. > By using a driver... data transfer could be as great as, or greater > than using a 'read' call, But you would be doing a "read" call to read from the driver anyway. The 4.2BSD "memory driver" copies stuff from kernel space to user space about as fast as it can be done - it uses a single "uiomove" call, which is what your driver would have to do. > perhaps using something similar to 'physio'? Not needed - "physio" is used for devices which do direct DMA access; the CPU can go through directly your machine's MMU to move stuff into user space. I'm not sure that anything is badly enough broken by being forced to do an "nlist" and read from "/dev/kmem" that a fix is called for. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy