Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!world!bzs From: bzs@world.std.com (Barry Shein) Newsgroups: comp.unix.internals Subject: Re: Interfaces for accessing kernel memory Message-ID: Date: 9 Dec 90 03:24:30 GMT References: <109449@convex.convex.com> <1410@mtxinu.COM> Sender: bzs@world.std.com (Barry Shein) Organization: The World Lines: 29 In-Reply-To: shore@mtxinu.COM's message of 1 Dec 90 23:33:31 GMT >There's certainly no reason that it has to be implemented as a system >call. Security is one consideration as most people like to keep /dev/kmem unreadable. But then again, a library would be more than useful for people developing privileged programs (certainly no *worse* than the current situation, and would work when/if the table() call became a common syscall.) Another, more subtle, consideration and one reason encore put this sort of stuff into system calls is that on multiprocessors the likelihood that the table you're looking at won't be "corrupted" (changed) as you read it becomes fleetingly small. At least a syscall can, optionally, lock the structure while it's being copied out. There's almost no way to do that thru the regular read/write interface on /dev/kmem (well, you can do anything, look at what the guy is reading etc, but forget it, a syscall here solves a real problem.) A library emulation would be a good idea. It would be a way for people to start moving their favorite utilities over and break the old chicken and egg compatability problem (and create a demand.) Should have been done years ago. -- -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD