On 25.03.2020 23:36, Jeff Law wrote:
> On Wed, 2020-03-18 at 20:29 +0100, Kamil Rytarowski wrote:
>> Set /tmp first, then /var/tmp. /tmp is volatile on NetBSD and
>> /var/tmp not. This improves performance in the common use.
>> The downstream copy of GCC was patched for this preference
>> since 2015.
>>
>> Remove occurence of /usr/tmp as it was never valid for NetBSD.
>> It was already activey disabled in the GCC manual page in 1996 and
>> in the GCC source code at least in 1998.
>>
>> This change is not a matter of user-preference but Operating
>> System defaults that disagree with the libiberty detection plan.
>>
>> No functional change for other Operataing Systems/environments.
>>
>> libiberty/ChangeLog:
>>
>>      * make-temp-file.c (choose_tmpdir): Honor NetBSD specific paths.
>> ---
>>  libiberty/ChangeLog        | 4 ++++
>>  libiberty/make-temp-file.c | 8 +++++++-
>>  2 files changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/libiberty/ChangeLog b/libiberty/ChangeLog
>> index 106c107e91a..18b9357aaed 100644
>> --- a/libiberty/ChangeLog
>> +++ b/libiberty/ChangeLog
>> @@ -1,3 +1,7 @@
>> +2020-03-18  Kamil Rytarowski  <n...@gmx.com>
>> +
>> +    * make-temp-file.c (choose_tmpdir): Honor NetBSD specific paths.
> I'd strongly recommend against this as-is.
>
> The whole reason we prefer /var/tmp is because it's often dramatically larger
> than a ram-backed /tmp.
>

NetBSD supports swap whenever /tmp is too small. Whenever tmpfs+ram are
too small, users use /tmp that is a regular directory (if I am not
wrong, this is still the default setup from an installer).

In NetBSD we want to use a non-persistent storage for performance
reasons. /var/tmp also affects negatively modern SSD devices with
needless writes.

It would be enough to get these try_dir paths tuned at least from
preprocessor during libiberty build for gdb/gcc/etc.

> I wouldn't mind dropping /usr/tmp.  That so antiquated that it'd be non-
> controversial.  Can you send that as a separate patch.
>

Behavior for !__NetBSD__ is out of interest.

> Jeff
>>
>

Reply via email to