--- /spare/tmp/linux-2.5.2-pre7/include/asm-i386/io.h Sun Dec 16 18:43:31 2001
+++ linux_2_5/include/asm-i386/io.h Fri Jan 4 12:32:07 2002
@@ -41,8 +41,6 @@
#define XQUAD_PORTIO_BASE 0xfe400000
#define XQUAD_PORTIO_LEN 0x40000 /* 256k per quad. Only remapping 1st */
-#ifdef __KERNEL__
-
#include <linux/vmalloc.h>
/*
@@ -108,16 +106,16 @@
* memory location directly.
*/
-#define readb(addr) (*(volatile unsigned char *) __io_virt(addr))
-#define readw(addr) (*(volatile unsigned short *) __io_virt(addr))
-#define readl(addr) (*(volatile unsigned int *) __io_virt(addr))
+#define readb(addr) (*(volatile u8 *) __io_virt(addr))
+#define readw(addr) (*(volatile u16 *) __io_virt(addr))
+#define readl(addr) (*(volatile u32 *) __io_virt(addr))
#define __raw_readb readb
#define __raw_readw readw
#define __raw_readl readl
-#define writeb(b,addr) (*(volatile unsigned char *) __io_virt(addr) = (b))
-#define writew(b,addr) (*(volatile unsigned short *) __io_virt(addr) = (b))
-#define writel(b,addr) (*(volatile unsigned int *) __io_virt(addr) = (b))
+#define writeb(b,addr) (*(volatile u8 *) __io_virt(addr) = (b))
+#define writew(b,addr) (*(volatile u16 *) __io_virt(addr) = (b))
+#define writel(b,addr) (*(volatile u32 *) __io_virt(addr) = (b))
#define __raw_writeb writeb
#define __raw_writew writew
#define __raw_writel writel
@@ -215,8 +213,6 @@
#define flush_write_buffers()
#endif
-
-#endif /* __KERNEL__ */
#ifdef SLOW_IO_BY_JUMPING
#define __SLOW_DOWN_IO "\njmp 1f\n1:\tjmp 1f\n1:"
On Fri, 4 Jan 2002, Jeff Garzik wrote:
> As we are now in 2.5.x series I figured it might be a good time to push
> this out... The patch removes __KERNEL__ ifdefs from [only] io.h as a
> nudge to userspace that they should not be including kernel headers.
Why not..
#ifndef __KERNEL__
#error This file should not be included by userspace.
#endif
?
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
Dave Jones wrote:
>
> On Fri, 4 Jan 2002, Jeff Garzik wrote:
>
> > As we are now in 2.5.x series I figured it might be a good time to push
> > this out... The patch removes __KERNEL__ ifdefs from [only] io.h as a
> > nudge to userspace that they should not be including kernel headers.
>
> Why not..
>
> #ifndef __KERNEL__
> #error This file should not be included by userspace.
> #endif
I thought about it, but then the tree would be littered with that all
over the place. Programmers are smart enough to figure this out (I hope
:))
--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno
On Fri, 4 Jan 2002, Jeff Garzik wrote:
> > #ifndef __KERNEL__
> > #error This file should not be included by userspace.
> > #endif
> I thought about it, but then the tree would be littered with that all
> over the place. Programmers are smart enough to figure this out (I hope
> :))
I doubt you'd need it in that many places. A few well chosen ones should
probably suffice.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Fri, 4 Jan 2002, Jeff Garzik wrote:
> Dave Jones wrote:
> >
> > On Fri, 4 Jan 2002, Jeff Garzik wrote:
> >
> > > As we are now in 2.5.x series I figured it might be a good time to push
> > > this out... The patch removes __KERNEL__ ifdefs from [only] io.h as a
> > > nudge to userspace that they should not be including kernel headers.
> >
> > Why not..
> >
> > #ifndef __KERNEL__
> > #error This file should not be included by userspace.
> > #endif
>
> I thought about it, but then the tree would be littered with that all
> over the place. Programmers are smart enough to figure this out (I hope
> :))
You can put it in config.h or the like where it gets included by everyone.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
[email protected] said:
> I doubt you'd need it in that many places. A few well chosen ones
> should probably suffice.
Just putting it asm-*/types.h should just about be enough.
--
dwmw2
Dave Jones wrote:
>
> On Fri, 4 Jan 2002, Jeff Garzik wrote:
>
> > > #ifndef __KERNEL__
> > > #error This file should not be included by userspace.
> > > #endif
> > I thought about it, but then the tree would be littered with that all
> > over the place. Programmers are smart enough to figure this out (I hope
> > :))
>
> I doubt you'd need it in that many places. A few well chosen ones should
> probably suffice.
oh, if Linus would apply it, I would love to see the above code in
asm/types.h or linux/kernel.h or similarly popular headers.
But... my patch is merely a small step, a "nudge" as I mentioned. I
don't want to annhilate the glibc developers with a sudden task, just a
nudge :)
Jeff
--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno
On Fri, 4 Jan 2002, Jeff Garzik wrote:
> But... my patch is merely a small step, a "nudge" as I mentioned. I
> don't want to annhilate the glibc developers with a sudden task, just a
> nudge :)
Then s/#error/#warning/ 8)
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
> Just putting it asm-*/types.h should just about be enough.
That is one of the headers glibc wants to import however. It wants to be
hard for applications to do something stupid but easy for glibc to extract
the relevant data that it actually needs (because glibc needs the kernel to
user information to make syscalls even if it doesnt expose them to apps)
Alan
Jeff Garzik writes:
> Dave Jones wrote:
> >
> > On Fri, 4 Jan 2002, Jeff Garzik wrote:
> >
> > > > #ifndef __KERNEL__
> > > > #error This file should not be included by userspace.
> > > > #endif
> > > I thought about it, but then the tree would be littered with that all
> > > over the place. Programmers are smart enough to figure this out (I hope
> > > :))
> >
> > I doubt you'd need it in that many places. A few well chosen ones should
> > probably suffice.
>
> oh, if Linus would apply it, I would love to see the above code in
> asm/types.h or linux/kernel.h or similarly popular headers.
>
> But... my patch is merely a small step, a "nudge" as I mentioned. I
> don't want to annhilate the glibc developers with a sudden task, just a
> nudge :)
Please test this change on a libc5 system before unleashing a
potential horror. All the world *is not* glibc!
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
Richard Gooch wrote:
> Please test this change on a libc5 system before unleashing a
> potential horror. All the world *is not* glibc!
(1) This is a devel series, the time for such changes, and (2) and it's
easy enough for libc5 systems to include their own sanitized copy of
kernel headers just like MDK, RHAT, and others are doing now for glibc.
Jeff
--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno
On Fri, 4 Jan 2002, Richard Gooch wrote:
> Please test this change on a libc5 system before unleashing a
> potential horror. All the world *is not* glibc!
Am I alone in finding the idea of running 2.5/2.6 on a libc5
system a little strange ?
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
Dave Jones writes:
> On Fri, 4 Jan 2002, Richard Gooch wrote:
>
> > Please test this change on a libc5 system before unleashing a
> > potential horror. All the world *is not* glibc!
>
> Am I alone in finding the idea of running 2.5/2.6 on a libc5
> system a little strange ?
Not if you want a lightweight C library. Such as when running off a CF
card.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
Alan Cox wrote:
>
> > Just putting it asm-*/types.h should just about be enough.
>
> That is one of the headers glibc wants to import however. It wants to be
> hard for applications to do something stupid but easy for glibc to extract
> the relevant data that it actually needs (because glibc needs the kernel to
> user information to make syscalls even if it doesnt expose them to apps)
Thinking -long term- here, I wonder what a good solution for glibc would
be? Userspace including glibc should never include kernel headers but I
100% agree we should make it as easy as possible for glibc (and other
libc's) to stay in sync with the kernel<->userspace API.
I am betting glibc does not require as much work to become independent
of kernel headers... it is more work to get all the userspace apps that
reference ioctl structures and constants not using kernel headers.
Jeff
--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno
On Fri, Jan 04, 2002 at 11:41:47AM -0700, Richard Gooch wrote:
> Not if you want a lightweight C library. Such as when running off a CF
> card.
But aren't there better options for a lightweight C library than libc5?
At least that would involve using something that's being maintained.
mrc
--
Mike Castle [email protected] http://www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
On Fri, 2002-01-04 at 13:16, Mike Castle wrote:
> On Fri, Jan 04, 2002 at 11:41:47AM -0700, Richard Gooch wrote:
> > Not if you want a lightweight C library. Such as when running off a CF
> > card.
>
> But aren't there better options for a lightweight C library than libc5?
>
> At least that would involve using something that's being maintained.
>
Yes indeed, something like this perhaps?
http://www.fefe.de/dietlibc/
Regards,
Reid
--
Ignorance of all things is an evil neither terrible nor excessive, nor
yet the greatest of all; but great cleverness and much learning, if they
be accompanied by a bad training, are a much greater misfortune. - Plato