search for: uvesa

> > This isn't unreasonable but there are drivers with userspace helpers that > > use iopl/ioperm type functionality where you should be doing a SELECT of > > X86_IOPORT. The one that comes to mind is the uvesa driver. From a quick > > scan it may these days be the only mainstream one that needs the select > > adding. > > Should kernel drivers really express dependencies that only their > (current instances of) corresponding userspace components need? > Something seems wrong about...

> > This isn't unreasonable but there are drivers with userspace helpers that > > use iopl/ioperm type functionality where you should be doing a SELECT of > > X86_IOPORT. The one that comes to mind is the uvesa driver. From a quick > > scan it may these days be the only mainstream one that needs the select > > adding. > > Should kernel drivers really express dependencies that only their > (current instances of) corresponding userspace components need? > Something seems wrong about...

...these > syscalls, so X86_IOPORT does not depend on EXPERT, though it does still > default to y. This isn't unreasonable but there are drivers with userspace helpers that use iopl/ioperm type functionality where you should be doing a SELECT of X86_IOPORT. The one that comes to mind is the uvesa driver. From a quick scan it may these days be the only mainstream one that needs the select adding. Some X servers for legacy cards still use io port access. There are also a couple of other highly non-obvious userspace users that hang on for some systems - eg some older servers DMI and error rec...

...these > syscalls, so X86_IOPORT does not depend on EXPERT, though it does still > default to y. This isn't unreasonable but there are drivers with userspace helpers that use iopl/ioperm type functionality where you should be doing a SELECT of X86_IOPORT. The one that comes to mind is the uvesa driver. From a quick scan it may these days be the only mainstream one that needs the select adding. Some X servers for legacy cards still use io port access. There are also a couple of other highly non-obvious userspace users that hang on for some systems - eg some older servers DMI and error rec...

https://bugs.freedesktop.org/show_bug.cgi?id=84706 Bug ID: 84706 Summary: [NV94] HDMI Connected, but TV reports "no signal" Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau

...86_IOPORT does not depend on EXPERT, though it does still > > default to y. > > This isn't unreasonable but there are drivers with userspace helpers that > use iopl/ioperm type functionality where you should be doing a SELECT of > X86_IOPORT. The one that comes to mind is the uvesa driver. From a quick > scan it may these days be the only mainstream one that needs the select > adding. Should kernel drivers really express dependencies that only their (current instances of) corresponding userspace components need? Something seems wrong about that. > Some X servers fo...

...03, 2014 at 03:27:48PM +0000, One Thousand Gnomes wrote: > > > This isn't unreasonable but there are drivers with userspace helpers that > > > use iopl/ioperm type functionality where you should be doing a SELECT of > > > X86_IOPORT. The one that comes to mind is the uvesa driver. From a quick > > > scan it may these days be the only mainstream one that needs the select > > > adding. > > > > Should kernel drivers really express dependencies that only their > > (current instances of) corresponding userspace components need? > &g...

On 11/03/2014 07:27 AM, One Thousand Gnomes wrote: >>> This isn't unreasonable but there are drivers with userspace helpers that >>> use iopl/ioperm type functionality where you should be doing a SELECT of >>> X86_IOPORT. The one that comes to mind is the uvesa driver. From a quick >>> scan it may these days be the only mainstream one that needs the select >>> adding. >> >> Should kernel drivers really express dependencies that only their >> (current instances of) corresponding userspace components need? >> Someth...

I''ve uploaded updated 2.6.31 and 2.6.32 rebased openSUSE Xen dom0 patches and ebuilds to http://code.google.com/p/gentoo-xen-kernel/downloads/list Notable change is that both include the online resize feature recently posted to xen-devel. Andy _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users

On the vast majority of modern systems, no processes will use the userspsace IO syscalls, iopl and ioperm. Add a new config option, CONFIG_X86_IOPORT, to support configuring them out of the kernel entirely. Most current systems do not run programs using these syscalls, so X86_IOPORT does not depend on EXPERT, though it does still default to y. In addition to saving a significant amount of

On the vast majority of modern systems, no processes will use the userspsace IO syscalls, iopl and ioperm. Add a new config option, CONFIG_X86_IOPORT, to support configuring them out of the kernel entirely. Most current systems do not run programs using these syscalls, so X86_IOPORT does not depend on EXPERT, though it does still default to y. In addition to saving a significant amount of

This patch series makes it possible to compile out the userspace IO system calls, iopl and ioperm. The first patch does some 32/64 unification in copy_thread to make subsequent changes easier. The second patch simplifies the complex calculation of the TSS segment limit, which also makes it easier to change in the last patch. Patches 3-9 introduce helpers to make it easier to compile out IO.

This patch series makes it possible to compile out the userspace IO system calls, iopl and ioperm. The first patch does some 32/64 unification in copy_thread to make subsequent changes easier. The second patch simplifies the complex calculation of the TSS segment limit, which also makes it easier to change in the last patch. Patches 3-9 introduce helpers to make it easier to compile out IO.