Date: Thu, 16 Apr 1998 16:22:40 -0400 (EDT) From: Bernie Doehner <bad@ece.WPI.EDU> To: Mike Smith <mike@smith.net.au> Cc: Bernie Doehner <bad@ece.WPI.EDU>, hackers@FreeBSD.ORG, buaas@wireless.net, bad@wireless.net Subject: Re: Documentation of 2.2.5-RELEASE and 3.0 memory protection? Message-ID: <Pine.OSF.3.96.980416160956.31725I-100000@taz.WPI.EDU> In-Reply-To: <199804120138.SAA00618@antipodes.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Sat, 11 Apr 1998 18:38:15 -0700 > From: Mike Smith <mike@smith.net.au> > To: Bernie Doehner <bad@ece.WPI.EDU> > Cc: hackers@freebsd.org > Subject: Re: Documentation of 2.2.5-RELEASE and 3.0 memory protection? > > > Is there a document that describes the kernel memory protection/allocation > > scheme used in 2.2.5-RELEASE and 3.0? > > > > I am especially interested in a list of io-space and io-memory ranges > > which I am allowed to read/write from in user space without > > worrying about interfering/overlapping into the kernel's memory space. > > Ah, I think you may have a slight misunderstanding here. > > Normally, you can't execute *any* I/O instructions from user space, nor > can you access memory in the ISA "hole". > > Opening /dev/io sets the IOPL flag for your process, which allows > unrestricted I/O access. When doing this, you're effectively on your Which is what we are presently doing, right.. I am just "checking" on the sane'ness of our approach. > own - the kernel will definitely be upset if you attempt to use any of > the "standard" peripheral components, as well as if you interfere with > any peripheral that it believes it controls. > > If you want to access memory on an expansion card in the ISA "hole", > you need to memory-map it into your process. You need a cooperative > driver for this - syscons allows you to memory-map video memory, and > AFAIR it's not too picky about the offset you specify. > But I don't see that being done in practice (or I wasn't able to wind my way through the kernel sources - probably more likely)... I compared the if_ed driver (some cards use shared memory, but in the ISA hole of A0000-100000), to the Digiboard driver (which I thought uses shared memory, but BELOW A0000). The Digiboard driver pmap_mapdev's the address, but if_ed does NOT.. Our shared memory is in the ISA hole and we currently do not pmap_mapdev. buaas@wireless.net has also written another driver (for Dianatel switch) which lived in monochrome memory, and he also didn't mmap and it seemed it worked ok. Thanks Bernie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.OSF.3.96.980416160956.31725I-100000>