Further cleanup <sys/io.h> for glibc 2.2

[Mark Kettenis]

   From: Andreas Jaeger <aj@suse.de>
   Date: 29 Jan 2000 13:21:15 +0100

Andreas, the report that prompted you to make these changes mentioned
that the problem occurred with glibc-2.1.3pre1.  I believe that -pre1
was made *after* the inclusion of <asm/io.h> was removed from
<sys/io.h> but *before* the inline I/O functions were added.

Ulrich, could you please try to add a ChangeLog entry when you make a
semi-public or public release.  That would make determining whether a
bug has already been fixed somewhat easier.

   I'm not really happy with this patch - the changes in glibc 2.1.3 to
   <sys/io.h> lead to the introduction of new symbols with version 2.1.3.

   Do we really want to have these functions with version 2.1.3?

I don't think so, and I'm not sure whether we want to add those
functions to 2.2.  Let me explain:

The origional <asm/io.h> that comes with the Linux kernel, and that we
previously included from <sys/io.h> uses `extern inline'.  Linus is on
record for saying that he uses `extern inline' in places where he
would otherwise use a macro, and expects those functions to be
*always* inlined by the compiler.  He complained to the GCC folks when
some `extern inlines' in the kernel were no longer inlined.

Of course this is a bit annoying, but we should realise that by
changing this, we're modifying *existing* behaviour.  If people think
that is OK, we have several options:

 * Turn the I/O functions into macros.  This is what most closely
   mimicks Linus' intentions because the code will always be
   "inlined", but we lose type-checking and debugging becomes a bit
   annoying.

 * Keep things as they are, but emit a warning when <sys/io.h> is
   included in a file that is compiled without optimization.  There is
   still the possibility that the compiler doesn't inline a I/O
   functions and will produce a linker warning though.

 * Use `static inline' instead.  The user won't notice when I/O
   functions aren't inlined when compiling without optimization,
   except that the program becomes a bit larger (but probably not more
   than a few bytes).

 * Provide public entry-points for the I/O functions.  This introduces
   potential versioning problems, although their impact would probably
   notbe noticable.  The I/O functions are only used in a few programs
   and everyone who uses a sane compiler and -O when compiling these
   programs will not introduce a dependency on the new, versioned symbols.

Personally I think providing entry-points for the I/O functions is
overkill, and I would go for the `static inline' approach.

Mark