Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!saimiri.primate.wisc.edu!sdd.hp.com!col.hp.com!csn!boulder!ucsu!rintintin.Colorado.EDU!galbrait From: galbrait@rintintin.Colorado.EDU (GALBRAITH JOHN) Subject: /dev/mem and /sys/i386/i386/mem.c Message-ID: <1993May28.222533.24315@ucsu.Colorado.EDU> Sender: news@ucsu.Colorado.EDU (USENET News System) Nntp-Posting-Host: rintintin.colorado.edu Organization: University of Colorado, Boulder Date: Fri, 28 May 1993 22:25:33 GMT Lines: 27 I was wondering if somebody could clarify what happens when you read/write to /dev/mem in the locations that are supposed to be mapped to the I/O bus. The man page says something about I/O being located in /dev/mem between 0x10000 to 0xa0000. When I look at /sys/i386/i386/mem.c, I can't see how this is going to work. Isn't there normal memory at those locations? mem.c does not appear to be written to support writes anyway, just reads. On a similar note, has anybody patched mem.c to support /dev/ioportb and /dev/ioportw? I have hacked a little bit on this without success. My test program opens a file on /dev/ioportb, does an lseek(), and then a write() (writes one byte only.) The file is successfully opened, the lseek() call returns correctly with no error message or anything, and then it goes to mem.c. The uio structure is not correct at this point. The uio_rw field is correct, I believe, as is the direction (sorry, I can't remember the name of the field.) However, the uio_offset field is way off as is the uio_resid. Shouldn't the lseek() call have set the uio_offset field? Also, the call to write specifies one byte only (the third parameter is a 1) and should set the uio_resid to 1, right? It ends up trying to do many writes to some random address, and all hell breaks loose. What is wrong with my reasoning? thanks, john galbraith galbrait@rintintin.colorado.edu