tun/tun.patch@4a34d7a82eab (annotated)
tun/tun.patch
Tue, 29 Mar 2011 20:04:34 +0200
- author
- Michael Schloh von Bennewitz <michael@schloh.com>
- date
- Tue, 29 Mar 2011 20:04:34 +0200
- changeset 334
- 4a34d7a82eab
- child 667
- 9dacbd1d1aa2
- permissions
- -rw-r--r--
Rework package yet again, correcting and introducing new buildconf logic:
Conditionally disable bootstrap stage comparison correctly, correct
english grammar, better find system as(1) and ld(1), indotruce detailed
optimization option messages, more completely guess cpu types, allow
profiled bootstrapping without a preinstalled GCC because many other
compilers have long since implemented 64-bit arithmetic, instruct make
to build sequentially (not in sparallel) when building a profiled
bootstrap as GCC online documents recommend, and generally improve
comment blocks.
The single most important correction in this changeset relates to the
GCC changed optimization policy since at least GCC 4.5, in which -march
is always passed and not always correctly guessed. In the case of this
package, allowing GCC to guess the architecture leads to wild build
errors at various subcomponents (zlib, libgcc, libiberty...) and
bootstrap stages. It seems quite platform specific, and the safest
approach to correcting this seems to be explicitly always specifying the
-march argument when bootstrapping GCC. Because the best choice 'native'
is not available when bootstrapping using a foreign (non GCC) compiler,
a guess is made according to rpmmacros l_platform in that case.
It is questionable as to whether these recent optimization changes
on the part of GCC or this package are compatible with each other,
or if either are complete or correct at all. At least applying these
corrections allows this package to build again in most cases test.
| michael@75 | 1 | Index: linux/2.2/tun.c |
| michael@75 | 2 | --- linux/2.2/tun.c.orig 2006-10-10 14:45:00.338589000 +0200 |
| michael@75 | 3 | +++ linux/2.2/tun.c 2006-10-10 14:44:05.695404000 +0200 |
| michael@75 | 4 | @@ -178,10 +178,22 @@ |
| michael@75 | 5 | |
| michael@75 | 6 | DBG( KERN_INFO "%s: tun_chr_poll\n", tun->name); |
| michael@75 | 7 | |
| michael@75 | 8 | + /* Data written to the /dev/tunX device is immediately placed into a socket buffer, making it |
| michael@75 | 9 | + * available to networking code at the tunX interface. Writes never block. |
| michael@75 | 10 | + * Likewise, data flows from the network stack, through the tunX interface and into the /dev/tun* device, |
| michael@75 | 11 | + * where it is queued, making it available for read(). |
| michael@75 | 12 | + * Thus the character device /dev/tunX is: |
| michael@75 | 13 | + * - readable if data was "transmitted" to the tunX interface and is now queued at the /dev/tunX device. |
| michael@75 | 14 | + * - always writable. |
| michael@75 | 15 | + * Everything written here is equally true of taps. |
| michael@75 | 16 | + * The author made a mistake when implementing this routine; he forgot that the device is always writable. |
| michael@75 | 17 | + * -jeff stearns 22-Dec-2005 |
| michael@75 | 18 | + */ |
| michael@75 | 19 | + |
| michael@75 | 20 | poll_wait(file, &tun->read_wait, wait); |
| michael@75 | 21 | |
| michael@75 | 22 | if( skb_queue_len(&tun->txq) ) |
| michael@75 | 23 | - return POLLIN | POLLRDNORM; |
| michael@75 | 24 | + return POLLIN | POLLRDNORM | POLLOUT | POLLWRNORM; |
| michael@75 | 25 | |
| michael@75 | 26 | return POLLOUT | POLLWRNORM; |
| michael@75 | 27 | } |
| michael@75 | 28 | Index: linux/2.4/tun.c |
| michael@75 | 29 | --- linux/2.4/tun.c.orig 2006-10-10 14:41:57.910408000 +0200 |
| michael@75 | 30 | +++ linux/2.4/tun.c 2006-10-10 14:43:40.067700000 +0200 |
| michael@75 | 31 | @@ -176,9 +176,21 @@ |
| michael@75 | 32 | DBG(KERN_INFO "%s: tun_chr_poll\n", tun->name); |
| michael@75 | 33 | |
| michael@75 | 34 | poll_wait(file, &tun->read_wait, wait); |
| michael@75 | 35 | + |
| michael@75 | 36 | + /* Data written to the /dev/tunX device is immediately placed into a socket buffer, making it |
| michael@75 | 37 | + * available to networking code at the tunX interface. Writes never block. |
| michael@75 | 38 | + * Likewise, data flows from the network stack, through the tunX interface and into the /dev/tun* device, |
| michael@75 | 39 | + * where it is queued, making it available for read(). |
| michael@75 | 40 | + * Thus the character device /dev/tunX is: |
| michael@75 | 41 | + * - readable if data was "transmitted" to the tunX interface and is now queued at the /dev/tunX device. |
| michael@75 | 42 | + * - always writable. |
| michael@75 | 43 | + * Everything written here is equally true of taps. |
| michael@75 | 44 | + * The author made a mistake when implementing this routine; he forgot that the device is always writable. |
| michael@75 | 45 | + * -jeff stearns 22-Dec-2005 |
| michael@75 | 46 | + */ |
| michael@75 | 47 | |
| michael@75 | 48 | if (skb_queue_len(&tun->txq)) |
| michael@75 | 49 | - return POLLIN | POLLRDNORM; |
| michael@75 | 50 | + return POLLIN | POLLRDNORM | POLLOUT | POLLWRNORM; |
| michael@75 | 51 | |
| michael@75 | 52 | return POLLOUT | POLLWRNORM; |
| michael@75 | 53 | } |
