On Sat, 9 Aug 2008, Peter Jeremy wrote:
On 2008-Aug-09 12:08:42 +0100, Robert Watson <[EMAIL PROTECTED]> wrote:
While /dev/io appeals to the UNIX "everything is a file" sensibility, I
think the system calls we have for this on i386 are more conceptually
coherent.
IMO, /dev/io is inherently a kludge - it's really more a MAC issue than
anything like a file. Whilst you get a FD by opening /dev/io, you never use
that FD for anything other than passing to close(2). Instead, you are using
a magic side-effect that allows you to execute 'in' and 'out' instructions
whilst you hold that FD open. AFAIK, the sole reason for having it appear
as a file is that (in the absence of a MAC framework), the filesystem
provides the only mechanism for access control. IMHO, /dev/io should be
deprecated in favour of something like the MAC framework. (Note that
i386_{g,s}et_ioperm(2) are nor suitable in their current form because there
is no mechanism for the system administrator to define access controls).
Well, the MAC Framework is basically an object/method control mechanism, and
appropriate for use with different sorts of objects and methods (we have quite
a few). It doesn't specify how the service is delivered, though. What I like
about i386_{g,s}et_ioperm(2) is that they set qualities on a process (cleared
on exeve(2), I hope), and if we have different priv(9) privileges for them,
they can be separately controlled.
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"