Discussion of a possible modern alternate of the removed Sysctl syscall

Discussion of a possible modern alternate of the removed Sysctl syscall

[Luís Mendes]

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

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.


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?

I am available to contribute with implementation, despite not being so
well familiarized with the Linux kernel code and development, but I
will do my best to provide an RFC implementation. Provided some small
guidance.


The facts:

The removal of the sysctl syscall caused Glibc to drop sys/io.h
emulation for ioperm, iopl, inb and outb for armhf.

-> commit 61a47c1ad3a4dc6882f01ebdc88138ac62d0df03
Author: Eric W. Biederman
Date:   Tue Oct 1 13:01:19 2019 -0500

    sysctl: Remove the sysctl system call

    This system call has been deprecated almost since it was introduced, and
    in a survey of the linux distributions I can no longer find any of them
    that enable CONFIG_SYSCTL_SYSCALL.  The only indication that I can find
    that anyone might care is that a few of the defconfigs in the kernel
    enable CONFIG_SYSCTL_SYSCALL.  However this appears in only 31 of 414
    defconfigs in the kernel, so I suspect this symbols presence is simply
    because it is harmless to include rather than because it is necessary.

    As there appear to be no users of the sysctl system call, remove the
    code.  As this removes one of the few uses of the internal kernel mount
    of proc I hope this allows for even more simplifications of the proc
    filesystem.


The Glibc maintainers found no evidence of current users for the
sys/io.h on armhf at the time:

-> commit 6b33f373c7b9199e00ba5fbafd94ac9bfb4337b1
Author: Florian Weimer
Date:   Wed May 29 16:53:09 2019 +0200

    arm: Remove ioperm/iopl/inb/inw/inl/outb/outw/outl support

    Linux only supports the required ISA sysctls on StrongARM devices,
    which are armv4 and no longer tested during glibc development
    and probably bit-rotted by this point.  (No reported test results,
    and the last discussion of armv4 support was in the glibc 2.19
    release notes.)


Then, to my surprise, I found this discussion:

http://sourceware-org.1504.n7.nabble.com/ioperm-support-for-Arm-td574053.html

"Do we still need this?  I'm not sure how many kernels/boards support the
ISA bus today. "

"All that said, I don't imagine anybody would notice if the
ioperm() support in glibc were to go away, and in the unlikely
event that there is some application somewhere that relies on it,
it wouldn't be very difficult to patch ioperm() into the
application itself.  It doesn't interact with anything else
inside glibc. "

Except that PCIe can also benefit from this.


Regards,

Luís Mendes

Aparapi open-source project developer (www.aparapi.com)

PhD Student and Researcher

Re: Discussion of a possible modern alternate of the removed Sysctl syscall

[Greg KH]

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 :)

thanks,

greg k-h

Re: Discussion of a possible modern alternate of the removed Sysctl syscall

[Luís Mendes]

Hi Greg,

Replies follow below.

Thanks,
Luis

On Wed, Jun 16, 2021 at 3:28 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> 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"?

armhf is a common acronym for arm 32-bits with an hardware floating point unit.

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

I understand that. It is just that since it is allowed and has been
allowed on x86_64 for a long time, and is in use by many
applications... so that for simplicity and cross-compatibility that it
could be made available once again for armhf as it was up until kernel
5.5 and the glibc version available at that time.
If the roadmap for user applications is towards UIO api, while
deprecating the inb, outb, I will have a look at that API for armhf. I
do know that mmap will not work for accessing PCIe IO spaces for
armhf, or at least not consistently across kernel versions, from my
experience. It only worked for PCIe memory regions. I will re-check
all that.

>
> > 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.
>
I have tried mmap for PCIe I/O spaces but it didn't work on arhmf. It
only works for memory regions, or at least it was like that, last time
I tried. Regarding UIO I confess I have not tried UIO yet.

> > 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 :)

I believe it had to do with user permissions management for accessing
I/O regions. Anyway all that code has been stripped off glibc once the
sysfs syscall was removed.

>
> thanks,
>
> greg k-h

Re: Discussion of a possible modern alternate of the removed Sysctl syscall

[Eric W. Biederman]

Greg KH <gregkh@linuxfoundation.org> 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

Re: Discussion of a possible modern alternate of the removed Sysctl syscall

[Greg KH]

On Wed, Jun 16, 2021 at 04:35:32PM +0100, Luís Mendes wrote:
> Hi Greg,
> 
> Replies follow below.
> 
> Thanks,
> Luis
> 
> On Wed, Jun 16, 2021 at 3:28 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > 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"?
> 
> armhf is a common acronym for arm 32-bits with an hardware floating point unit.
> 
> >
> > > 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.)
> 
> I understand that. It is just that since it is allowed and has been
> allowed on x86_64 for a long time, and is in use by many
> applications...

Was it really in use by any arm systems in a way that worked?  IO ports
were semi-standardized in some places on x86, but NEVER on arm, so what
programs used them that need to do so in a cross-platform way?

> so that for simplicity and cross-compatibility that it
> could be made available once again for armhf as it was up until kernel
> 5.5 and the glibc version available at that time.

But the backing hardware is so different, why does it need to be
"compatible"?  What programs are using this on arm that expect to do so
in a way that would also work on x86?  What hardware accesses are they
wanting to do?

> If the roadmap for user applications is towards UIO api, while
> deprecating the inb, outb, I will have a look at that API for armhf. I
> do know that mmap will not work for accessing PCIe IO spaces for
> armhf, or at least not consistently across kernel versions, from my
> experience. It only worked for PCIe memory regions. I will re-check
> all that.

mmap works with the UIO api, please look into that, it's what it is
there for when you know _EXACTLY_ what hardware you have and want to
access it directly from userspace.

thanks,

greg k-h

Re: Discussion of a possible modern alternate of the removed Sysctl syscall

[Luís Mendes]

Replies follow below.

Thanks,
Luís
On Wed, Jun 16, 2021 at 4:57 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Wed, Jun 16, 2021 at 04:35:32PM +0100, Luís Mendes wrote:
> > Hi Greg,
> >
> > Replies follow below.
> >
> > Thanks,
> > Luis
> >
> > On Wed, Jun 16, 2021 at 3:28 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > 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"?
> >
> > armhf is a common acronym for arm 32-bits with an hardware floating point unit.
> >
> > >
> > > > 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.)
> >
> > I understand that. It is just that since it is allowed and has been
> > allowed on x86_64 for a long time, and is in use by many
> > applications...
>
> Was it really in use by any arm systems in a way that worked?  IO ports
> were semi-standardized in some places on x86, but NEVER on arm, so what
> programs used them that need to do so in a cross-platform way?

I had it working on two systems of mine, one with imx6q and another
with mvebu (Armada 388), besides the x86_64.
All it was needed was to make the address ranges available for the
inb/outb emulations. For imx6q all it was needed was:
Edit arch/arm/mach-imx/mach-imx6q.c, function __init
imx6q_init_late(void) and append:
   register_isa_ports(0xfee0000, 0x1f80000, 0);
This would make the PCIe IO memory region available for the inb/outb
emulations through glibc and the same code would run on armhf and
x86_64.
It is possible that some arm chips may have a non-fixed memory map,
and as such, that each consumer appliance ends up with different
memory maps, but that could be handled by the device tree if needed.
So surely it is possible to have it working in a cross-platform way.
That is somehow the OS job, to hide hardware differences between
devices, and if it is possible to do so between architectures I argue
that is even better for the user code.
I do understand that this may be a deprecated API, but if that is the
case, then why isn't it deprecated for all systems?

Existing applications that make use of this are diverse, I am not
aware of all of them, but for instance there is this one:
https://www.nongnu.org/avrdude/
another example, could be this one:
http://www.embeddedlinux.org.cn/EmbLinux/ch07.htm

There are diverse reports of compilation failures on the Internet for
armhf and aarch64 that are related to sys/io.h and inb/outb and
friends. Some relevant examples follow below, where I list four web
links for such issues. The first one even provides an alternate
implementation for aarch64
(https://github.com/machinekit/machinekit/issues/1269).

>
> > so that for simplicity and cross-compatibility that it
> > could be made available once again for armhf as it was up until kernel
> > 5.5 and the glibc version available at that time.
>
> But the backing hardware is so different, why does it need to be
> "compatible"?  What programs are using this on arm that expect to do so
> in a way that would also work on x86?  What hardware accesses are they
> wanting to do?
It is not an absolute requirement for sure, since applications can
also adapt to other APIs, but let me grab some cases reported that are
found on the internet:
https://github.com/machinekit/machinekit/issues/1269
https://bugzilla.redhat.com/show_bug.cgi?id=1116162
https://archlinuxarm.org/forum/viewtopic.php?f=9&t=14462
https://community.nxp.com/t5/i-MX-Processors/fatal-error-sys-io-h-file-not-found/td-p/1087388

For my particular case, the application is cross-platform, it supports
x86_64 (Windows/Linux) and armhf (Linux) it was tested and working on
those platforms since 2015, although it has no user base besides me at
the moment, I would like to make it available once I get the code
cleaned-up. By making use of code portability through glibc it was the
case that x86_64 and armhf implementations shared the same code for
Linux, and differed very little for Windows support through MingW. The
application makes use of a PCIe Multi-function IO card with serial and
parallel interfaces that is accessed through the corresponding
Parallel SPP/ECP registers (LPT). By accessing the SPP/ECP registers
directly it is possible to achieve higher throughput when generating
different serial protocols by bit-banging the LPT IO lines directly.
There is always the ppdev driver which also gives access to the
hardware IO lines from user-space, except that it is slow, requiring
multiple ioctl calls.
Examples: http://www.embeddedlinux.org.cn/EmbLinux/ch07lev1sec3.htm vs
http://www.embeddedlinux.org.cn/EmbLinux/ch07.htm

"
>
> > If the roadmap for user applications is towards UIO api, while
> > deprecating the inb, outb, I will have a look at that API for armhf. I
> > do know that mmap will not work for accessing PCIe IO spaces for
> > armhf, or at least not consistently across kernel versions, from my
> > experience. It only worked for PCIe memory regions. I will re-check
> > all that.
>
> mmap works with the UIO api, please look into that, it's what it is
> there for when you know _EXACTLY_ what hardware you have and want to
> access it directly from userspace.

I have to have a look at that, for sure.

>
> thanks,
>
> greg k-h