Difference between revisions of "Platform Notes (GNU HURD)"
Jump to navigation
Jump to search
(Created page with "== Port Status == GNU HURD is a Tier 3 Port. == Testing Details == The GNU HURD port is built and tested on the following system: * ESXi Virtual Machine (32-bit) * 4GB R...") |
|||
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
== Port Status == | == Port Status == | ||
GNU HURD is a [[Tier 3 Port]]. | GNU HURD is a [[Tier 3 Port]]. | ||
| + | |||
| + | == Verified Releases == | ||
| + | N/A | ||
== Testing Details == | == Testing Details == | ||
| Line 13: | Line 16: | ||
== Required Kernel Tuning == | == Required Kernel Tuning == | ||
| − | + | GNU HURD seems to adjust its IPC limits dynamically, as IPC is a user-space subsystem. | |
== Port Challenges == | == Port Challenges == | ||
| − | * GNU HURD lacks System V semaphore operations, though shared memory is supported -- we're looking at using | + | * GNU HURD lacks System V semaphore operations, though shared memory is supported -- we're looking at using <code>fcntl</code> locks as a workaround |
| − | * File I/O operations seem to regularly freeze the daemon and raise CPU usage to 85% or higher on the | + | * File I/O operations seem to regularly freeze the daemon and raise CPU usage to 85% or higher on the <code>ext2fs</code> process |
| + | |||
| + | [[Category:Tier 3 Ports]] | ||
| + | [[Category:Platform Notes]] | ||
Latest revision as of 18:03, 4 August 2023
Contents
Port Status
GNU HURD is a Tier 3 Port.
Verified Releases
N/A
Testing Details
The GNU HURD port is built and tested on the following system:
- ESXi Virtual Machine (32-bit)
- 4GB RAM
- GNU polemos 0.9 GNU-Mach 1.8+git20230526-486/Hurd-0.9 i686-AT386 GNU
- gcc 12.2.0-14+hurd.1
- autoconf 2.71
- automake 1.16.5
Required Kernel Tuning
GNU HURD seems to adjust its IPC limits dynamically, as IPC is a user-space subsystem.
Port Challenges
- GNU HURD lacks System V semaphore operations, though shared memory is supported -- we're looking at using
fcntllocks as a workaround - File I/O operations seem to regularly freeze the daemon and raise CPU usage to 85% or higher on the
ext2fsprocess
