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

[Andreas Jaeger <aj at suse dot de>]

>>>>> Mark Kettenis writes:

 >    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.
You're right.

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

Thanks for the excellent analysis.

static inline is fine with me - since it works if we compile without
optimisation.

The current solution doesn't work without optimisation- and that's
something we should take care of.  Even if it doesn't work without
optimisation when including <asm/io.h> is no excuse for me - if we
include those functions in glibc, we should do it correctly.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.rhein-neckar.de