Re: [PATCH v4 10/10] x86: Support compiling out userspace IO (iopl and ioperm)

On 11/03/2014 07:27 AM, One Thousand Gnomes wrote:

quoted

quoted

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.

uvesafb will always need X86_IOPORT. It's kind of implicit in the design.
I'm not suggesting that fbdev should select X86_IOPORT but in the uvesafb
case at least it's completely useless to have one and not the other.

Are there any users of uvesafb at all?  Last time I changed that driver,
I tried to test it, and I was unable to find a copy of the userspace helper.

--Andy

quoted

IO_BITMAP_LONGS already gets defined to (0/sizeof(long)).  And as far as
I can tell, that would only work for init_tss_io, not anything else.
Even then, that would only work with a zero-size array left around in
tss_struct, which doesn't seem appropriate.  The remaining ifdefs wrap
code that GCC could not constant-fold away, and making that code
constant-foldable seems significantly more invasive than the ifdefs.

OK