* Further cleanup <sys/io.h> for glibc 2.2
@ 2000-01-29 4:23 Andreas Jaeger
2000-01-29 5:43 ` Mark Kettenis
0 siblings, 1 reply; 3+ messages in thread
From: Andreas Jaeger @ 2000-01-29 4:23 UTC (permalink / raw)
To: GNU libc hacker
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?
A corresponding patch for 2.1.3 will follow later,
Andreas
2000-01-29 Andreas Jaeger <aj@suse.de>
* sysdeps/unix/sysv/linux/i386/Versions: Add functions from
<sys/io.h> with version 2.1.3.
* sysdeps/unix/sysv/linux/i386/Makefile (sysdep_routines): Add
io-inlines.
* sysdeps/unix/sysv/linux/i386/io-inlines.c: New file, used for
implementation of extern inline functions.
* sysdeps/unix/sysv/linux/alpha/sys/io.h: Add missing ints.
============================================================
Index: sysdeps/unix/sysv/linux/i386/Versions
--- sysdeps/unix/sysv/linux/i386/Versions 2000/01/29 12:02:47 1.5
+++ sysdeps/unix/sysv/linux/i386/Versions 2000/01/29 12:20:18
@@ -7,6 +7,10 @@
GLIBC_2.1 {
__modify_ldt; modify_ldt;
}
+ GLIBC_2.1.3 {
+ inb; inb_p; inl; inl_p; insb; insl; insw; inw; inw_p;
+ outb; outb_p; outl; outl_p; outsb; outsl; outsw; outw; outw_p;
+ }
GLIBC_2.2 {
# New rlimit interface
getrlimit; setrlimit; getrlimit64;
============================================================
Index: sysdeps/unix/sysv/linux/i386/Makefile
--- sysdeps/unix/sysv/linux/i386/Makefile 2000/01/24 12:07:00 1.18
+++ sysdeps/unix/sysv/linux/i386/Makefile 2000/01/29 12:20:18
@@ -1,5 +1,6 @@
ifeq ($(subdir),misc)
-sysdep_routines += ioperm iopl vm86 setfsgid setfsuid setresgid setresuid
+sysdep_routines += ioperm iopl vm86 setfsgid setfsuid setresgid setresuid \
+ io-inlines
sysdep_headers += sys/elf.h sys/perm.h sys/reg.h sys/vm86.h sys/debugreg.h sys/io.h
endif
============================================================
Index: sysdeps/unix/sysv/linux/alpha/sys/io.h
--- sysdeps/unix/sysv/linux/alpha/sys/io.h 2000/01/23 08:53:21 1.5
+++ sysdeps/unix/sysv/linux/alpha/sys/io.h 2000/01/29 12:20:18
@@ -1,4 +1,4 @@
-/* Copyright (C) 1996, 1999 Free Software Foundation, Inc.
+/* Copyright (C) 1996, 1999, 2000 Free Software Foundation, Inc.
This file is part of the GNU C Library.
The GNU C Library is free software; you can redistribute it and/or
@@ -65,12 +65,12 @@
unsigned char *__buf) __THROW;
/* Userspace declarations. */
-extern unsigned int inb (unsigned long __port) __THROW;
-extern unsigned int inw (unsigned long __port) __THROW;
-extern unsigned int inl (unsigned long __port) __THROW;
-extern void outb (unsigned char __b, unsigned long __port) __THROW;
-extern void outw (unsigned short __w, unsigned long __port) __THROW;
-extern void outl (unsigned int __l, unsigned long __port) __THROW;
+extern unsigned int inb (unsigned long int __port) __THROW;
+extern unsigned int inw (unsigned long int __port) __THROW;
+extern unsigned int inl (unsigned long int __port) __THROW;
+extern void outb (unsigned char __b, unsigned long int __port) __THROW;
+extern void outw (unsigned short int __w, unsigned long int __port) __THROW;
+extern void outl (unsigned int __l, unsigned long int __port) __THROW;
__END_DECLS
============================================================
Index: sysdeps/unix/sysv/linux/i386/io-inlines.c
--- sysdeps/unix/sysv/linux/i386/io-inlines.c created
+++ sysdeps/unix/sysv/linux/i386/io-inlines.c Sat Jan 29 13:14:40 2000 1.1
@@ -0,0 +1,24 @@
+/* Copyright (C) 2000 Free Software Foundation, Inc.
+ This file is part of the GNU C Library.
+
+ The GNU C Library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Library General Public License as
+ published by the Free Software Foundation; either version 2 of the
+ License, or (at your option) any later version.
+
+ The GNU C Library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Library General Public License for more details.
+
+ You should have received a copy of the GNU Library General Public
+ License along with the GNU C Library; see the file COPYING.LIB. If not,
+ write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ Boston, MA 02111-1307, USA. */
+
+/* <sys/io.h> declares some extern inline functions. These functions
+ are declared additionally here if inlining is not possible. */
+
+#define _EXTERN_INLINE /* empty */
+
+#include <sys/io.h>
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.rhein-neckar.de
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Further cleanup <sys/io.h> for glibc 2.2
2000-01-29 4:23 Further cleanup <sys/io.h> for glibc 2.2 Andreas Jaeger
@ 2000-01-29 5:43 ` Mark Kettenis
2000-01-29 10:02 ` Andreas Jaeger
0 siblings, 1 reply; 3+ messages in thread
From: Mark Kettenis @ 2000-01-29 5:43 UTC (permalink / raw)
To: aj; +Cc: libc-hacker
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Further cleanup <sys/io.h> for glibc 2.2
2000-01-29 5:43 ` Mark Kettenis
@ 2000-01-29 10:02 ` Andreas Jaeger
0 siblings, 0 replies; 3+ messages in thread
From: Andreas Jaeger @ 2000-01-29 10:02 UTC (permalink / raw)
To: Mark Kettenis; +Cc: libc-hacker
>>>>> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2000-01-29 10:02 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-01-29 4:23 Further cleanup <sys/io.h> for glibc 2.2 Andreas Jaeger
2000-01-29 5:43 ` Mark Kettenis
2000-01-29 10:02 ` Andreas Jaeger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).