From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 24 11:57:12 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 8F7601065670; Sun, 24 Oct 2010 11:57:12 +0000 (UTC) Date: Sun, 24 Oct 2010 11:57:12 +0000 From: Alexander Best To: Garrett Cooper Message-ID: <20101024115712.GA61342@freebsd.org> References: <20101024002248.GA73346@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-hackers@freebsd.org Subject: Re: fix pnpinfo on arch=amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 11:57:12 -0000 On Sat Oct 23 10, Garrett Cooper wrote: > On Sat, Oct 23, 2010 at 5:22 PM, Alexander Best wrote: > > this tiny patch will fix pnpinfo so it doesn't core dump (bus error) any > > longer on arch=amd64. > > 1. I had to modify the Makefile to get it to work. probably because you built pnpinfo from contrib/pnpinfo and not from usr.sbin/pnpinfo. i'm not sure your changes to contrib/pnpinfo/Makefile are according to current practice. maybe the vendor Makefile shouldn't be modified and every additional stuff should rather go into usr.sbin/pnpinfo/Makefile. but i don't really know. also in the in usr.sbin/pnpinfo/makefile there's a check for PC98 that i'm not sure is really needed. > 2. FWIW, I don't there's really much point in adding a check for only > x86 architectures, if the tool is capable of more than that. yeah you're probably right. to be honest i know nothing about "archs != i386|amd64". ;) so i just added the amd64 option, because i didn't want to break pnpinfo on other platforms. > 3. Might as well close the file descriptor after opening it. right. expecially, because opening /dev/io (even in ro mode) is a huge security issue. so better close it asap. of course on i386/amd64 (maybe pc98 too?) i386_set_ioperm(2) could be used to work around the security issue. but since pnpinfo's job is to access hardware directly i think opening /dev/io directly can be consideren ok. > > SIGBUS occurs because it doesn't have permission to write via outb. > It's a shame that there isn't a more proper way to catch this SIGBUS > fault minus adding a SIGBUS handler (but that might have other > undesired side effects). well on i386/amd (pc98?) you could use i386_get_ioperm(2) to check for proper io permissions. > Thanks, > -Garrett -- a13x