From owner-freebsd-hackers Thu Apr 16 13:24:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA21506 for freebsd-hackers-outgoing; Thu, 16 Apr 1998 13:24:17 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ece.WPI.EDU (root@ece.WPI.EDU [130.215.16.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA21260 for ; Thu, 16 Apr 1998 20:23:46 GMT (envelope-from bad@ece.WPI.EDU) Received: from taz.WPI.EDU (bad@taz.WPI.EDU [130.215.16.19]) by ece.WPI.EDU (8.8.5/8.6) with ESMTP id QAA29495; Thu, 16 Apr 1998 16:23:34 -0400 (EDT) Received: from localhost (bad@localhost) by taz.WPI.EDU (8.8.5/8.6) with SMTP id QAA31285; Thu, 16 Apr 1998 16:22:40 -0400 (EDT) X-Authentication-Warning: taz.WPI.EDU: bad owned process doing -bs Date: Thu, 16 Apr 1998 16:22:40 -0400 (EDT) From: Bernie Doehner To: Mike Smith cc: Bernie Doehner , hackers@FreeBSD.ORG, buaas@wireless.net, bad@wireless.net Subject: Re: Documentation of 2.2.5-RELEASE and 3.0 memory protection? In-Reply-To: <199804120138.SAA00618@antipodes.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Date: Sat, 11 Apr 1998 18:38:15 -0700 > From: Mike Smith > To: Bernie Doehner > 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