This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
>>>>> 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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |