Browse code
Update PORTS
Instead of fully removing PORTS, keep "this is what you want to do for
porting OpenVPN to a new platform" section, and update the PLATFORMS
part to better reflect current status.
v2:
drop "2.2+" from Linux, and name the fruitish thing "macOS"
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Frank Lichtenheld <frank@lichtenheld.com>
Message-Id: <20221128111642.3483-1-gert@greenie.muc.de>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg25558.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
Gert Doering authored on 2022/11/28 20:16:42Showing 1 changed files
| ... | ... |
@@ -11,20 +11,31 @@ Copyright (C) 2002-2022 OpenVPN Inc <sales@openvpn.net> |
| 11 | 11 |
|
| 12 | 12 |
PLATFORM STATUS: |
| 13 | 13 |
|
| 14 |
- * Linux 2.2+ (supported) |
|
| 15 |
- * Solaris (supported) |
|
| 16 |
- * OpenBSD 3.0 (supported but pthreads are broken) |
|
| 17 |
- * Max OS X Darwin |
|
| 14 |
+Tier 1 platforms - actively tested for every source commit, across |
|
| 15 |
+multiple operating system versions |
|
| 16 |
+ |
|
| 17 |
+ * Windows 7 and newer |
|
| 18 |
+ * Windows Server 2012 and newer |
|
| 19 |
+ * Linux |
|
| 18 | 20 |
* FreeBSD |
| 21 |
+ * macOS |
|
| 22 |
+ |
|
| 23 |
+Tier 2 platforms - it worked at some point, but is not actively tested |
|
| 24 |
+on "latest OS, latest OS libraries" so might break if larger changes |
|
| 25 |
+are done on the platform side |
|
| 26 |
+ |
|
| 27 |
+ * OpenBSD |
|
| 19 | 28 |
* NetBSD |
| 20 |
- * Windows |
|
| 21 |
- * 64 bit platforms -- I have heard reports that |
|
| 22 |
- OpenVPN runs on Alpha Linux and FreeBSD. |
|
| 23 |
- * ARM -- I have heard of at least one case |
|
| 24 |
- where OpenVPN was successfully built and |
|
| 25 |
- run on the ARM architecture. |
|
| 29 |
+ * DragonFly BSD |
|
| 30 |
+ * Solaris |
|
| 31 |
+ * AIX |
|
| 32 |
+ |
|
| 33 |
+For underlying CPU architecture, everything 32 bit or 64 bit (Intel, AMD, |
|
| 34 |
+ARM, PowerPC, SPARC*) should work fine. 16 bit Architectures are unlikely |
|
| 35 |
+to work. |
|
| 36 |
+ |
|
| 26 | 37 |
|
| 27 |
-PORTING NOTES: |
|
| 38 |
+PORTING GUIDELINE TO A NEW PLATFORM: |
|
| 28 | 39 |
|
| 29 | 40 |
* Make sure that OpenSSL will build on your |
| 30 | 41 |
platform. |
| ... | ... |
@@ -42,7 +53,7 @@ PORTING NOTES: |
| 42 | 42 |
function in tun.c to generate a correct "ifconfig" |
| 43 | 43 |
command for your platform. Note that OpenVPN |
| 44 | 44 |
determines the ifconfig path at ./configure time. |
| 45 |
- * Add an ifconfig_order() variant for your OS so |
|
| 45 |
+ * Possibly add an ifconfig_order() variant for your OS so |
|
| 46 | 46 |
openvpn knows whether to call ifconfig before |
| 47 | 47 |
or after tun/tap dev open. |
| 48 | 48 |
* Add an #ifdef TARGET_YOUROS block in tun.c and define |
| ... | ... |
@@ -77,12 +88,8 @@ PORTING NOTES: |
| 77 | 77 |
disabled with an explicit ioctl call if cross-platform |
| 78 | 78 |
compatibility is to be preserved. You can see some |
| 79 | 79 |
examples of this in tun.c. |
| 80 |
- * If your system supports pthreads, try building |
|
| 81 |
- with ./configure --enable-pthread and do a stress |
|
| 82 |
- test in TLS mode. |
|
| 83 |
- * Try the ultimate stress test which is --gremlin |
|
| 84 |
- --reneg-sec 10 in TLS mode (preferably with pthreads |
|
| 85 |
- enabled), then do a flood ping across the tunnel |
|
| 80 |
+ * Try the ultimate stress test which is --gremlin --reneg-sec 10 |
|
| 81 |
+ in TLS mode then do a flood ping across the tunnel |
|
| 86 | 82 |
(ping -f remote-endpoint) in both directions and let |
| 87 | 83 |
it run overnight. --gremlin will induce massive |
| 88 | 84 |
corruption and packet loss, but you win if you |