Date: Fri, 30 Jul 1999 13:11:25 -0600 From: Warner Losh <imp@village.org> To: Mike Smith <mike@smith.net.au> Cc: Mike Smith <msmith@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/usr.sbin/apm apm.c Message-ID: <199907301911.NAA83225@harmony.village.org> In-Reply-To: Your message of "Fri, 30 Jul 1999 11:43:41 PDT." <199907301843.LAA00424@dingo.cdrom.com> References: <199907301843.LAA00424@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199907301843.LAA00424@dingo.cdrom.com> Mike Smith writes: : I'm not entirely sure yet about the ramifications of user-space code : being able to call the BIOS; there are security and locking implications : that I want to consider, and a good case for a more generalised : interface. What are the security implications? Only root or group operator, by default, can do this. Your point about the locking mechanism is well taken. Nothing else is doing any locking, so the same problem exists with the information interface. I'm not sure why you say that it can't work. It is just using the same mechansim that the the get information stuff is using... Data structures in memory aren't supported accross this interface... : APM should also become a module (real soon now), which will take the : pressure off on any "vendor specific" features as well; so far we don't : actually support anything "vendor specific" anyway, so it's a bit of a : furphy right now. Right now there are a couple of information producing programs that use this interface. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907301911.NAA83225>