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: >>> 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 10/10] x86: Support compiling out userspace IO (iopl and ioperm)
On Mon, Nov 03, 2014 at 03:27:48PM +, 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 10/10] x86: Support compiling out userspace IO (iopl and ioperm)
On Mon, Nov 03, 2014 at 12:10:49PM +, One Thousand Gnomes wrote: > On Sun, 2 Nov 2014 09:33:01 -0800 > Josh Triplett wrote: > > > 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. > > 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 for legacy cards still use io port access. Sure, X servers using UMS rather than KMS seem like a common reason to need this. > 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 records can only by > read via a real mode BIOS call so management tools have no choice but to > go the lrmi/io path. As with any userspace interface, some callers may potentially still exist. And this still has "default y", too, to avoid user surprises. > Still makes sense IMHO. > > From a code perspective however you could define IO_BITMAP_LONGS to 0, > add an IO_BITMAP_SIZE (defined as LONGS + 1 or 0) and as far as I can see > gcc would then optimise out a lot of the code you are ifdeffing 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. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 10/10] x86: Support compiling out userspace IO (iopl and ioperm)
On Sun, 2 Nov 2014 09:33:01 -0800 Josh Triplett wrote: > 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. 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 records can only by read via a real mode BIOS call so management tools have no choice but to go the lrmi/io path. Still makes sense IMHO. >From a code perspective however you could define IO_BITMAP_LONGS to 0, add an IO_BITMAP_SIZE (defined as LONGS + 1 or 0) and as far as I can see gcc would then optimise out a lot of the code you are ifdeffing Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
