Linux Virtualization - Nov 2014 - [PATCH v4 10/10] x86: Support compiling out userspace IO (iopl and ioperm)

> > 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.
> 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

On Mon, Nov 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?
> > 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.
OK, fair enough.  Do you want the patch series respun to add that select
in patch 10/10, or would you consider it sufficient to add that in a
followup patch, since the kernel will build and boot either way (so it
won't break bisection)?

Related to that: Is it intentional that FB_UVESA doesn't depend on X86,
even though FB_VESA does?  Does v86d run on non-x86 hardware via
emulation?  If so, should FB_UVESA have "select X86_IOPORT if X86"?

- Josh Triplett

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?
>> 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
> 
>> 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
>