[PATCH 0/3] Fix initialization when iopl is forbidden
simon.farnsworth at onelan.com
Wed Jul 18 11:00:00 PDT 2012
On Tuesday 26 June 2012 16:33:44 Adam Jackson wrote:
> The following series, when combined with appropriate DDX driver fixes,
> allows X to initialize without a config file even when iopl/ioperm are
> unavailable on an architecture which otherwise has them. This is useful
> when the system security policy forbids it, for example for UEFI Secure
> Boot compliance.
> The requisite driver changes, assuming you're not trying to work against
> arbitrary server ABIs, amount to "if xorgHWAccess is exported at build
> time, check it early in probe". This happens to be source-compatible
> with a fairly long range of servers due to xf86Priv.h inexplicably being
> an SDK header despite the name. That's a mistake we ought to fix, so
> subsequent to this series the declaration moves to xf86.h.
> Tested with a KMS radeon config on F17.
> common/xf86.h | 1
> common/xf86Bus.c | 11 -----
> common/xf86Configure.c | 27 -------------
> common/xf86Init.c | 23 +++++------
> common/xf86Priv.h | 1
> os-support/linux/lnx_video.c | 89
> 6 files changed, 63 insertions(+), 89 deletions(-)
For the whole series:
Reviewed-by: Simon Farnsworth <simon.farnsworth at onelan.co.uk>
I twice thought I'd seen bugs, but a closer look showed me wrong - the huge
chain of "#if !defined(<arch>) || !defined(<arch>)" in lnx_video.c being
replaced by a smaller chain of "if defined(<arch>) || defined(<arch>)" caught me
at first, but appears to be what was actually intended.
The sequence by which xorgHWAccess is changed from meaning "we want access" to
"we have access" between InitOutput and the driver probe function wasn't
It might be nice to mention in the comment in xf86Init.c where you say 'this
is "do we want it" at this point' that xf86BusConfig() will call xf86EnableIO()
when xorgHWAccess is TRUE, or move the call of xf86EnableIO() into InitOutput.
But that's nit-picking, so feel free to ignore me.
More information about the xorg-devel