search for: io_bitmap_size

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

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

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

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.