linux-kernel - Re: x86 status was Re: -mm merge plans for 2.6.23

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 12 Jul 2007 15:36:30 +0000 (UTC)
From:	Oleg Verych <for.gmane@...wer.upol.cz>
To:	linux-kernel@...r.kernel.org
Subject:  Re: x86 status was Re: -mm merge plans for 2.6.23

* Linus Torvalds "Wed, 11 Jul 2007 15:09:28 -0700 (PDT)"
>
> On Wed, 11 Jul 2007, Andrea Arcangeli wrote:
>>
>> I'm going to change topic big time because your sentence above
>> perfectly applies to the O(1) scheduler too.
>
> I disagree to a large degree.
>
> We almost never have problems with code you can "think about".
>
> Sure, bugs happen, but code that everybody runs the same generally doesn't 
> break. So a CPU scheduler doesn't worry me all that much. CPU schedulers 
> are "easy".
>
> What worries me is interfaces to hardware that we know looks different for 
> different people. That means that any testing that one person has done 
> doesn't necessarily translate to anything at *all* on another persons 
> machine.
>
> The timer problems we had when merging the stuff in 2.6.21 just scarred 
> me. I'd _really_ hate to have to go through that again. And no, the 
> "gradual" thing where the patch that actually *enables* something isn't 
> very gradual at all, so that's the absolutely worst kind of thing, because 
> then people can "git bisect" to the point where it got enabled and tell us 
> that's where things broke, but that doesn't actually say anything at all 
> about the patch that actually implements the new behaviour.
>
> So the "enable" kind of patch is actually the worst of the lot, when it 
> comes to hardware.
>
> When it comes to pure software algorithms, and things like schedulers, 
> you'll still obviously have timing issues and tuning, but generally things 
> *work*, which makes it a lot easier to debug and describe.
>
> 		Linus

Seconded (obviously).

--
-o--=O`C
 #oo'L O
<___=E M

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/