Maxime Villard wrote:
> In the first mail, you said that it was better to have a all-or-nothing
> sysctl, which is *exactly* what I just committed.
Yes, sysctl is better than giving rdtsc to root only. But "better"
alone isn't strong enough to count me as a supporter.
> In the second one, as a re
Le 03/10/2017 à 22:47, Alexander Nasonov a écrit :
Maxime Villard wrote:
In case you didn't notice, this sysctl results directly from the answers I
got, and is not my original plan (about which I changed my mind as a
consequence of the conversation). So now tell me exactly which point I didn't
c
Maxime Villard wrote:
> In case you didn't notice, this sysctl results directly from the answers I
> got, and is not my original plan (about which I changed my mind as a
> consequence of the conversation). So now tell me exactly which point I didn't
> consider and which reply I ignored. The thread
If pax mprotect is an example then maxv should just go around rm -rf'ing
any parts of the tree he doesn't like without even checking that the
kernel builds afterwards, since that's the way we do things around here.
It was months until I could run meld again, even disabling it for just
python was f
Le 03/10/2017 à 21:14, Joerg Sonnenberger a écrit :
I'm not responding to this nonsensical thread anymore, everything got told
months ago. The option is here, people don't need to give a damn about it
unless they explicitly want to - which is still legitimate in some cases,
including for kaslr, w
On Tue, Oct 03, 2017 at 06:54:52PM +0200, Maxime Villard wrote:
> Just like disabling va0 or enabling PaX mprotect; if you feel like these are
> no issues, then what's the fuss. You would be well served to read the "rdtsc
> is still enabled by default" part of my email.
Disabling va0 is low impact
On Mon, Oct 2, 2017 at 4:09 PM, Taylor R Campbell <
campbell+netbsd-source-change...@mumble.net> wrote:
> > Date: Mon, 2 Oct 2017 21:42:11 +0200
> > From: Joerg Sonnenberger
> >
> > On Mon, Oct 02, 2017 at 07:23:16PM +, Maxime Villard wrote:
> > > Add a machdep.tsc_user_enable sysctl, to enab
On Mon, Oct 2, 2017 at 4:43 PM, Joerg Sonnenberger wrote:
> On Mon, Oct 02, 2017 at 04:25:34PM -0600, Warner Losh wrote:
> > Even if you don't have the ability to change the defective hardware?
>
> The hardware is not defective. We are not talking about variable timing
> for basic arithmetic oper
On Tue, Oct 03, 2017 at 06:54:52PM +0200, Maxime Villard wrote:
> I'm not responding to this nonsensical thread anymore,
The problem is, you keep acting unilaterally without having gathered a
consensus, then ignoring the resulting objections and demanding to
have everything your way and only your
On Tue, Oct 03, 2017 at 07:53:41PM +0200, Kamil Rytarowski wrote:
> For a server or a product I wouldn't want to run such executables and I
> would use SECURE or HIGHLY-SECURE mode.
This is why for servers I rebuild a kernel with only what I need
(and in term of hardware drivers too).
And of cours
On 03.10.2017 19:27, Christos Zoulas wrote:
> On Oct 3, 7:03pm, m...@m00nbsd.net (Maxime Villard) wrote:
> -- Subject: Re: CVS commit: src/sys
>
> | What about you both cut the drama and the bullshit right here. What has been
> | said already repeatedly, again, and again, is that choosing one sid
On Oct 3, 7:03pm, m...@m00nbsd.net (Maxime Villard) wrote:
-- Subject: Re: CVS commit: src/sys
| What about you both cut the drama and the bullshit right here. What has been
| said already repeatedly, again, and again, is that choosing one side over the
| other just does not work. There is no "mo
Le 03/10/2017 à 18:53, Christos Zoulas a écrit :
In article <20171003162103.ga25...@britannica.bec.de>,
Joerg Sonnenberger wrote:
On Tue, Oct 03, 2017 at 04:03:49PM +0200, Maxime Villard wrote:
Le 03/10/2017 à 15:52, Kamil Rytarowski a écrit :
On 03.10.2017 15:35, Greg Troxel wrote:
Then, I
Le 03/10/2017 à 13:26, Joerg Sonnenberger a écrit :
At the same time, it has interesting interactions with power management
and the instruction queue.
The queue is flushed by a serializing instruction executed right before, which
is the recommended use case; the interaction with power managemen
In article <20171003162103.ga25...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Tue, Oct 03, 2017 at 04:03:49PM +0200, Maxime Villard wrote:
>> Le 03/10/2017 à 15:52, Kamil Rytarowski a écrit :
>> > On 03.10.2017 15:35, Greg Troxel wrote:
>> > > Then, I think the debate
>> > > reduces to "sh
On Tue, Oct 03, 2017 at 04:03:49PM +0200, Maxime Villard wrote:
> Le 03/10/2017 à 15:52, Kamil Rytarowski a écrit :
> > On 03.10.2017 15:35, Greg Troxel wrote:
> > > Then, I think the debate
> > > reduces to "should the checked-in GENERIC enable the emulation sysctl".
> >
> > I don't see a better
We can rump mount a lot of those filesystems, it would be nice if that
was be the default way too. A lot less risky
Le 03/10/2017 à 15:52, Kamil Rytarowski a écrit :
On 03.10.2017 15:35, Greg Troxel wrote:
Then, I think the debate
reduces to "should the checked-in GENERIC enable the emulation sysctl".
I don't see a better answer to this question: yes, no or depends on the
flavor of the kernel.
My personal
On 03.10.2017 15:35, Greg Troxel wrote:
> Then, I think the debate
> reduces to "should the checked-in GENERIC enable the emulation sysctl".
I don't see a better answer to this question: yes, no or depends on the
flavor of the kernel.
My personal preference is to keep it enabled by default, but I
Manuel Bouyer writes:
> On Mon, Oct 02, 2017 at 02:39:47PM +0200, Maxime Villard wrote:
>> > Actually I did suggest to make the default dependant on MODULAR.
>>
>> what's the point exactly?
>
> that if I build a non-modular kernel with an emulation option explicitely
> selected, it works at boo
On Tue, Oct 03, 2017 at 08:17:27AM +0200, Maxime Villard wrote:
> What is clear, however, is that the effort needed to perform accurate
> measurements in software is much higher than that needed to invoke a hardware
> instruction that will instantly give about the most accurate answer possible.
Ha
21 matches
Mail list logo
