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] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |