From owner-freebsd-hackers Sat Apr 11 18:40:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA19829 for freebsd-hackers-outgoing; Sat, 11 Apr 1998 18:40:47 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles220.castles.com [208.214.165.220]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA19819 for ; Sat, 11 Apr 1998 18:40:42 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id SAA00618; Sat, 11 Apr 1998 18:38:16 -0700 (PDT) Message-Id: <199804120138.SAA00618@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Bernie Doehner cc: hackers@FreeBSD.ORG Subject: Re: Documentation of 2.2.5-RELEASE and 3.0 memory protection? In-reply-to: Your message of "Sat, 11 Apr 1998 16:22:36 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 11 Apr 1998 18:38:15 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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 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. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message