Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> writes: > On Wed, Jun 16, 2021 at 02:40:13PM +0100, Luís Mendes wrote: >> Dear Linux kernel maintainers/developers, >> >> >> I would like to discuss a modern alternate to Sysctl syscall and its >> feasibility for armhf and aarch64 for supporting ioperm, iopl, inb, >> outb and their siblings APIs emulation in Glibc, or even on an >> external library to provide such sys/io.h API compatibility with >> x86_64. >> >> The advantage of having ioperm, iopl, inb and outb emulation for armhf > > What is "armhf"? > >> and aarch64 is that they can provide cross-compilation ability of >> x86_64 applications and constitutes an easy and practical API for >> simple I/O. This was not only useful for old ISA cards as it is today >> for PCIe cards with I/O space, like I/O cards, LPT Parallel interface >> cards, as well as many other cards that may have PCIe I/O space >> (network cards, etc). PCIe LPT interface cards as well as >> multi-function cards are still widely available, just search ebay or >> amazon, and many suggestions will pop up. >> >> I know for instance that LPT interface cards have their ppdev driver >> which already provides an ioctl interface to access the card I/O >> lines, but it is not performant for applications like bit-banging an >> LPT card to load firmware into a micro-controller, for instance, >> Microchip/ATMEL 8-bit micro-controllers. Plus the ioperm, iopl, inb, >> outb has a simpler API for doing simple interactions with the I/O >> space, like is the case with the IO lines of the LPT parallel >> interface card. > > You should never use iopl, inb, and outb on modern systems, sorry. > Please use the bus-specific ways to access the devices needed, or mmap > the needed memory ranges into your program and directly access them that > way if you know what you are doing for your specific hardware type (the > UIO api provides this for you.) > >> There are many complaints in the web, like bug reports and >> cross-compilation issues/reports regarding sys/io.h removal on armhf. >> There are also people wishing for such functionality on aarch64. >> >> >> I had an application working up to two years ago on two armhf systems >> (armv7) on imx6q and mvebu architectures, to be concrete. The >> application did and does just that, currently only for x84_64, but it >> is able to bit-bang the ports to load the firmware into the chips. I >> just didn't got to up-stream these quite small changes, like selecting >> (in the kernel configuration): >> General setup->Configure standard Kernel features (expert >> users)->Sysctl syscall support->Enable >> and do: >> arch/arm/mach-imx/mach-imx6q.c, function __init imx6q_init_late(void) >> and appended: >> >> register_isa_ports(0xfee0000, 0x1f80000, 0); >> >> Which is the PCIe IO memory region in the imx6q memory map. It was >> just a matter of up-streaming the change. It maybe also useful to >> rename register_isa_ports to register_pci_ports, or so in the kernel, >> to avoid this confusion regarding to ISA bus only applicability. > > As I stated above, you can access PCI IO memory regious through the UIO > api and mmap them and talk directly to them if you want to. There is no > need to do old-style inb commands anymore for stuff like this, and > hasn't been for decades now. > >> So I would like to have some opinions regarding the introduction of a >> modern alternate for the sysctl syscall update in order to achieve >> Glibc cross-compatibility for armhf and possibly aarch64 of what >> already exists in Glibc for x86_64. What do you say? > > sysctl should not have anything to do with i/o accesses. I don't know > how that got somehow tied together in glibc, but that seems like a glibc > issue, not a kernel one :) There is somewhere a sysctl that provides information needed for the emulation. Base addresses or something like that. I have only seen it mentioned briefly. This was one of the uses of sys_sysctl that was mentioned in the first conversation about removing it. The information should still be exported through /proc/sys/ Greg I will agree with you that whatever userspace is doing it should get the information in a modern way that supports multiple busses or at a bare minimum userspace should read the values it needs from the files under /proc/sys. I do sympathize as this appears to be a regression. Even if not all of the code was merged. The use case is one I am familiar with bring up code wanting easy access from userspace so people can experiment and figure out what is really going on with the hardware. Luis please see if you can use the interfaces that support multiple busses. That should be more robust in the future. Especially if you are bit-banging to load firmware or other userspace drivers, the is a reasonable chance your hardware will appear on a system with multiple busses someday and will actually need that support. Eric
