Bug 2210

Summary: [PATCH] Move sys/io.h to sysdeps/{i386,x86_64}/
Product: glibc Reporter: Robert Millan <rmh>
Component: libcAssignee: Ulrich Drepper <drepper.fsp>
Status: RESOLVED WONTFIX    
Severity: enhancement CC: glibc-bugs
Priority: P2 Flags: fweimer: security-
Version: unspecified   
Target Milestone: ---   
Host: Target:
Build: Last reconfirmed:
Attachments: move sys/io.h to sysdeps/{i386,x86_64}

Description Robert Millan 2006-01-26 07:58:08 UTC
Former discussion in libc-alpha (see
http://sources.redhat.com/ml/libc-alpha/2002-09/msg00153.html) suggests that it
is not a problem if sys/io.h declares iopl() when the system doesn't have it. 
Besides, iopl() can be implemented in userland when kernel offers an interface
with similar functionality (for kFreeBSD, we implemented it as a wrapper to
/dev/io).

If we count i386-pc-kfreebsd-gnu and x86_64-pc-kfreebsd-gnu, that'll be at least
5 platforms using a copy of the same sys/io.h file (only with cosmetical
differences).  I think it makes sense to move to sysdeps/i386 and sysdeps/x86_64
so that the file can be shared between them.

Please consider the attached patch.
Comment 1 Robert Millan 2006-01-26 08:00:59 UTC
Created attachment 848 [details]
move sys/io.h to sysdeps/{i386,x86_64}

2006-01-26  Robert Millan  <robertmh@gnu.org>

	* sysdeps/unix/sysv/linux/i386/sys/io.h:  Move to ...
	* sysdeps/i386/sys/io.h:  ... here.
	* sysdeps/mach/hurd/i386/sys/io.h:  Remove.

	* sysdeps/i386/Dist:  Add sys/io.h.
	* sysdeps/i386/Makefile:  Ditto.
	* sysdeps/mach/hurd/i386/Dist:	Remove sys/io.h.
	* sysdeps/mach/hurd/i386/Makefile:  Ditto.
	* sysdeps/unix/sysv/linux/i386/Dist:  Ditto.
	* sysdeps/unix/sysv/linux/i386/Makefile:  Ditto.

	* sysdeps/unix/sysv/linux/x86_64/sys/io.h:  Move to ...
	* sysdeps/x86_64/sys/io.h:  ... here.

	* sysdeps/x86_64/Dist:	Add sys/io.h.
	* sysdeps/x86_64/Makefile:  Ditto.
	* sysdeps/unix/sysv/linux/x86_64/Dist:	Remove sys/io.h.
	* sysdeps/unix/sysv/linux/x86_64/Makefile:  Ditto.
Comment 2 Ulrich Drepper 2006-02-03 22:16:37 UTC
And use comments mentioning Linux on Hurd etc?  Right...

Beside, for these kind of system specific headers I have no interest in handling
the fallout of changes just because some platforms wants to be slightly different.