Kamil Rytarowski wrote:
> I have checked LLDB and std::atomic is used on purpose and was
> switched from mutexes 3 years ago.
I guess that explains why so many packages now break on i386 because the
lack of 64 bit atomic operations. libreoffice and freeradius are that
last one I stumbled upon.
On Mon, May 11, 2020 at 01:11:32AM +0200, Kamil Rytarowski wrote:
> On 10.05.2020 18:38, Kamil Rytarowski wrote:
> > LLDB will be patched to avoid atomics.
> I have checked LLDB and std::atomic is used on purpose and was
> switched from mutexes 3 years ago.
>
>
On 10.05.2020 18:38, Kamil Rytarowski wrote:
> LLDB will be patched to avoid atomics.
I have checked LLDB and std::atomic is used on purpose and was
switched from mutexes 3 years ago.
https://github.com/llvm/llvm-project/commit/f9d16476573e16856bdb3250c817b0a2c631d2b1
Reverting this (or
On Sun, May 10, 2020 at 10:25:50PM +, Taylor R Campbell wrote:
> > Date: Sun, 10 May 2020 22:10:55 +
> > From: m...@netbsd.org
> >
> > I still don't find the getrandom man page you provided to be good, it
> > talks about "/dev/random behaviour" which is something you've changed to
> > not
> Date: Sun, 10 May 2020 22:10:55 +
> From: m...@netbsd.org
>
> I still don't find the getrandom man page you provided to be good, it
> talks about "/dev/random behaviour" which is something you've changed to
> not have this behaviour.
Can you be specific?
The phrase `/dev/random behaviour'
> That issue is why I'm not really happy about the getentropy API: it
> was originally defined to never block, and some systems have made it
> block for reasons that don't really mean very much.
>
> This is an argument for providing just getrandom -- the API contract
> is is clearer and doesn't
In article <9d775d79-026a-f52a-ae3c-39a00eea4...@gmx.com>,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>On 08.05.2020 21:33, m...@netbsd.org wrote:
>> On Fri, May 08, 2020 at 04:09:02PM +0200, Kamil Rytarowski wrote:
>>> I object to opinions that libatomic is generally broken, if that
Le dim. 10 mai 2020 à 22:16, Joerg Sonnenberger a écrit :
> Emitting libcalls for 128bit atomics when explicitly instructed that
> the support is present is a bug. That's why this is an issue with GCC
> and not with Clang.
Of course, no argument here, the GCC bug needs to be fixed regardless,
if
On Sun, May 10, 2020 at 10:03:27PM +0200, Jaromír Doleček wrote:
> Le dim. 10 mai 2020 à 20:25, Joerg Sonnenberger a écrit :
> > I find it funny that you pick an example where correctly working
> > atomic implementation is essential and where the only reason it is
> > pulled in is a bug in GCC.
>
On 10.05.2020 20:25, Joerg Sonnenberger wrote:
> On Sun, May 10, 2020 at 06:16:49PM +0200, Kamil Rytarowski wrote:
>> On 08.05.2020 21:33, m...@netbsd.org wrote:
>>> On Fri, May 08, 2020 at 04:09:02PM +0200, Kamil Rytarowski wrote:
I object to opinions that libatomic is generally broken, if
> Date: Sun, 10 May 2020 14:24:00 +0300
> From: Andreas Gustafsson
>
> The getentropy() man pages on OpenBSD, FreeBSD, and Linux all say it
> returns "high-quality" entropy, and do not caution against using it
> for security critical purposes such as key generation, so presumably
> applications
nia wrote:
> For years, the development hivemind's advice has been "/dev/random bad!
> always urandom!", because having interfaces that unpredictably block on
> you is a terrible idea.
Yes, that has been the advice. I think it's bad advice, but it's
understandable given the historical
On Sun, May 10, 2020 at 06:16:49PM +0200, Kamil Rytarowski wrote:
> On 08.05.2020 21:33, m...@netbsd.org wrote:
> > On Fri, May 08, 2020 at 04:09:02PM +0200, Kamil Rytarowski wrote:
> >> I object to opinions that libatomic is generally broken, if that would
> >> be the cause, it wouldn't be
On Sun, May 10, 2020 at 08:22:42PM +0300, Andreas Gustafsson wrote:
> Joerg Sonnenberger wrote:
> > We don't warn people about unavailable of 127.0.0.1/:: during very early
> > boot and a number of other issues either. If your application is running
> > during system initialisation, you are
Joerg Sonnenberger wrote:
> We don't warn people about unavailable of 127.0.0.1/:: during very early
> boot and a number of other issues either. If your application is running
> during system initialisation, you are supposed to be somewhat aware of
> the limitations in that case.
That's nonsense.
On 09.05.2020 18:51, Christos Zoulas wrote:
> I am with Martin here. This belongs in pkgsrc and not in base. There is
> an overhead using libatomic and we should not be penalizing everyone.
> There are very few cases where applications should be using raw atomics,
> and in these situations the
On Sun, May 10, 2020 at 02:24:00PM +0300, Andreas Gustafsson wrote:
> The getentropy() man pages on OpenBSD, FreeBSD, and Linux all say it
> returns "high-quality" entropy, and do not caution against using it
> for security critical purposes such as key generation, so presumably
> applications do
On 08.05.2020 21:33, m...@netbsd.org wrote:
> On Fri, May 08, 2020 at 04:09:02PM +0200, Kamil Rytarowski wrote:
>> I object to opinions that libatomic is generally broken, if that would
>> be the cause, it wouldn't be available and used on relatively all
>> relevant generic purpose Operating
Taylor R Campbell wrote:
> In NetBSD-current, there's a distinction between:
> - incorporating what samples we have, and
> - confidently achieving full entropy.
> This distinction is made between sources that maybe might have
> entropy, like interrupt timings, but we can't honestly put a lower
>
> Date: Sun, 10 May 2020 07:44:36 +0200
> From: Michael van Elst
>
> On Sun, May 10, 2020 at 05:23:37AM +, Taylor R Campbell wrote:
> > But how is this question relevant to the discussion at hand of whether
> > to adopt a de facto standard C API or which?
>
> It isn't.
Then please take it
20 matches
Mail list logo
