Re: outb(2): terminology correction

[Alejandro Colomar <alx@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2672 bytes --]

> Date: 2026-09-11 13:36:29+0200
> From: Alejandro Colomar <alx@kernel.org>
>
> [CC += GENERIC INCLUDE/ASM HEADER FILES maintainers]
> 
> Hi astian, Arnd,
> 
> > Date: 2026-08-31 09:09:46+0000
> > From: astian <astian@memeware.net>
> >
> > outb(2) says:
> > 
> >   You must compile with -O or -O2 or similar.  The functions are defined
> >   as inline macros, and will not be substituted in without optimization
> >   enabled, causing unresolved references at link time.
> > 
> > "inline macros [...] not substituted in without optimization" doesn't
> > make any sense.  C pre-processor macros cannot be inline or not inline.
> > Indeed these are inline *functions* (at least in this system) with
> > embedded assembly apparently referencing parameters (which, I surmise,
> > is why the functions need to be inlined by the compiler or the assembly
> > will not work).
> > 
> > From /usr/include/x86_64-linux-gnu/sys/io.h (glibc 2.43):
> > 
> >   [...]
> >   #if defined __GNUC__ && __GNUC__ >= 2
> > 
> >   static __inline unsigned char
> >   inb (unsigned short int __port)
> >   {
> >     unsigned char _v;
> > 
> >     __asm__ __volatile__ ("inb %w1,%0":"=a" (_v):"Nd" (__port));
> >     return _v;
> >   }
> > 
> >   [...]
> > 
> >   static __inline void
> >   outb (unsigned char __value, unsigned short int __port)
> >   {
> >     __asm__ __volatile__ ("outb %b0,%w1": :"a" (__value), "Nd" (__port));
> >   }
> > 
> >   [...]
> > 
> > So I would say just s/inline macros/inline functions/g.
> 
> Yes, 'inline functions' seems more appropriate than 'inline macros' (all
> macros are inlined, due to how the preprocessor works, so they'd be just
> macros, and as you showed, these are not even macros --except maybe in
> some architectures--).
> 
> However, I doubt the entire paragraph.  I don't know why inline
> functions would produce unresolved references at link time _even if they
> were not substituted_.  The point of inline functions is that they are
> sometimes inlined, and sometimes not, and the compiler does the right
> thing in both cases.
> 
> This seems like paranoia from decades ago, when inline functions were
> less known (and maybe compilers were more buggy than they are now).
> 
> Arnd, should we remove the paragraph entirely?  Or is there any obscure
> reason why optimizations are required?

Or maybe those assembly instructions are what causes the linker issues?
If so, we should probably say something about that.


Cheers,
Alex

> 
> 
> Have a lovely day!
> Alex 
> 
> -- 
> <https://www.alejandro-colomar.es>



-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]