On Thu, Mar 26, 2020 at 12:51:24AM +, Taylor R Campbell wrote:
> We should keep the change. There is no semantic justification for
> putting build-time temporary files in the directory for temporary
> files that are meant to persist across reboot. These temporary files
> _cannot_ be used if i
On 26.03.2020 09:48, Martin Husemann wrote:
> On Thu, Mar 26, 2020 at 12:51:24AM +, Taylor R Campbell wrote:
>> We should keep the change. There is no semantic justification for
>> putting build-time temporary files in the directory for temporary
>> files that are meant to persist across reboo
On Thu, Mar 26, 2020 at 02:57:40PM +0100, Kamil Rytarowski wrote:
> The build of tools could be fixed independently.
The problem is that we build the whole system with the tools gcc, and that
gcc misbehaves (or so I understood).
So pointing TMPDIR anywhere does not help.
Martin
On 26.03.2020 15:01, Martin Husemann wrote:
> On Thu, Mar 26, 2020 at 02:57:40PM +0100, Kamil Rytarowski wrote:
>> The build of tools could be fixed independently.
> The problem is that we build the whole system with the tools gcc, and that
> gcc misbehaves (or so I understood).
>
> So pointing TM
On Tue, Aug 14, 2018 at 02:49:14PM +, Maxime Villard wrote:
> Module Name: src
> Committed By: maxv
> Date: Tue Aug 14 14:49:14 UTC 2018
> Log Message:
> Retire EtherIP, we have L2TP instead.
Why was this not discussed? L2TP does not implement EtherIP
functionality, and is therefore
Kamil Rytarowski writes:
> On 26.03.2020 15:01, Martin Husemann wrote:
>> On Thu, Mar 26, 2020 at 02:57:40PM +0100, Kamil Rytarowski wrote:
>>> The build of tools could be fixed independently.
>> The problem is that we build the whole system with the tools gcc, and that
>> gcc misbehaves (or so I
Date:Thu, 26 Mar 2020 15:11:46 +0100
From:Kamil Rytarowski
Message-ID: <26eaf84f-616a-d48b-9a2f-7dd74cd69...@gmx.com>
| Right. Addressing tools build independently (honoring TMPDIR?)
This we should do.
| defining TMPDIR in /etc shell profile for common use insi
Greg Troxel writes:
> It seem really obvious to me, and obvious that it is netbsd consensus,
> that a tool that needs tmp (without needing persistence) should default
> to /tmp. So I think it's unreasonable to follow upstream here, and
> unreasonable to ask everybody to either inherit some syste
On 26.03.2020 15:52, Greg Troxel wrote:
> What is the real problem here? I think it's great that NetBSD-specific
> fixes are being upstreamed, and that we are reducing gratuitous changes
> from upstream. But upstream's position that the default tmp should be
> /var/tmp is at odds with our and tra
Generally speaking divergence with upstream is a problem and we lost
these changes anyway in pkgsrc and every standalone GNU toolchain copy.
Agreed that divergence is a problem, but so is having bugs. It's a
question of the right balance in each case.
Finding a creative way to make this at
On 26.03.2020 16:02, Robert Elz wrote:
> EVery extra env var has a cost in every exec of absolutely everything.
As this is true.. but as I have benchmarked it.
For true(1) on amd64, we execute 0.05% more instructions for extra
TMPDIR environment variable.
$ ./singlestepper true
Total count: 1286
> Date: Thu, 26 Mar 2020 14:57:40 +0100
> From: Kamil Rytarowski
>
> Maybe we could specify TMPDIR somewhere in /etc and point to /tmp?
>
> The build of tools could be fixed independently.
It is wrong for gcc to abuse /var/tmp for files that aren't
meaningfully persistent, just like it would be
On 26.03.2020 16:17, Greg Troxel wrote:
> I don't think we can go from "upstream is unwilling to do X"
> to "impose pain on NetBSD" by making "divergence bad" be the
> highest-weighted concern. We have to say "what is the minimally
> painful way to cope".
I agree here that we want to get /tmp by
On 26.03.2020 17:03, Kamil Rytarowski wrote:
> On 26.03.2020 16:17, Greg Troxel wrote:
>> I don't think we can go from "upstream is unwilling to do X"
>> to "impose pain on NetBSD" by making "divergence bad" be the
>> highest-weighted concern. We have to say "what is the minimally
>> painful way
Date:Thu, 26 Mar 2020 16:28:18 +0100
From:Kamil Rytarowski
Message-ID: <84460ebb-b4bf-f3ee-e51b-e27d0b6e2...@gmx.com>
| That is negligible cost of getting TMPDIR propagated to most programs.
Sure, it isn't much, for one program, but when you're running tens of
tho
On 26.03.2020 17:49, Robert Elz wrote:
> Date:Thu, 26 Mar 2020 16:28:18 +0100
> From:Kamil Rytarowski
> Message-ID: <84460ebb-b4bf-f3ee-e51b-e27d0b6e2...@gmx.com>
>
>
> | That is negligible cost of getting TMPDIR propagated to most programs.
>
> Sure, it isn't much,
Le 26/03/2020 à 15:32, Jonathan A. Kollasch a écrit :
> On Tue, Aug 14, 2018 at 02:49:14PM +, Maxime Villard wrote:
>> Module Name: src
>> Committed By:maxv
>> Date:Tue Aug 14 14:49:14 UTC 2018
>> Log Message:
>> Retire EtherIP, we have L2TP instead.
>
> Why was this no
Date:Thu, 26 Mar 2020 18:07:54 +0100
From:Kamil Rytarowski
Message-ID: <723e979c-cb16-1a39-a51e-9d756f372...@gmx.com>
| But nonetheless, I'm trying to fix it un GCC without TMPDIR.
Not without, just without requiring. Something like tempnam(3)
works - if TMPDIR i
On Thu, Mar 26, 2020 at 06:07:54PM +0100, Kamil Rytarowski wrote:
> On 26.03.2020 17:49, Robert Elz wrote:
> > Date:Thu, 26 Mar 2020 16:28:18 +0100
> > From:Kamil Rytarowski
> > Message-ID: <84460ebb-b4bf-f3ee-e51b-e27d0b6e2...@gmx.com>
> >
> >
> > | That is negligi
On Thu, Mar 26, 2020 at 10:54:21AM +0700, Robert Elz wrote:
> Date:Wed, 25 Mar 2020 20:51:25 +
> From:David Holland
> Message-ID: <20200325205125.ga11...@netbsd.org>
>
> | I don't agree -- because applications shouldn't attempt to modify the
> | result, it sho
Date:Thu, 26 Mar 2020 23:22:57 +
From:Andrew Doran
Message-ID: <20200326232257.gf27...@homeworld.netbsd.org>
| > Modern CPUs like Ryzen Threadripper 3990X can execute that extra amount
| > of instructions (around 600) in a single clock cycle.
|
| NetBSD-cu
21 matches
Mail list logo
