linux-kernel - Re: -mm merge plans for 2.6.20

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:	Tue, 5 Dec 2006 20:30:13 -0800
From:	Andrew Morton <akpm@...l.org>
To:	Roman Zippel <zippel@...ux-m68k.org>
Cc:	linux-kernel@...r.kernel.org, tglx@...utronix.de,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: -mm merge plans for 2.6.20

> On Wed, 6 Dec 2006 03:59:41 +0100 (CET) Roman Zippel <zippel@...ux-m68k.org> wrote:
> Hi,
> 
> On Mon, 4 Dec 2006, Andrew Morton wrote:
> 
> > [dyntick]
> > 
> >  Shall merge, I guess.  My confidence is low, but it's Kconfigurable and it
> >  needs to get sorted out.
> 
> IMO it least at needs one more iteration to address the comments that 
> were made (not just mine), in the short term the less it touches 
> unconditionally the less I care right now.

I don't have a clue which review comments remain unaddressed - do you recall?

I never saw an item-by-item accounting of my own (extensive) review
comments, actually.  And then an avalanche of new stuff got sent and I
didn't have time to go through it all at the same level of detail.

So yeah, I don't have a lot of confidence from that POV either.  But otoh,
I'm confident that Ingo and Thomas will competently and promptly address
regressions, so the risk factor isn't too bad.  And changing APIC and
timekeeping code sure is risky.

Yes, I too am wobbly about a 2.6.20 merge.  But otoh I doubt if much will
get changed if it sits in -mm for another two months.  As long as it's
heading in the right direction and doesn't break things when it is
configged-off then OK.

> In the long term IMO this might need a major rework, the basic problem I 
> have is that I don't see how this usable beyond dynticks/hrtimer, e.g. how 
> to dynamically manage multiple timer.

I'm not sure I understand that.  Are you referring to multiple,
concurrently-operating hardware clock sources?  <wonders how that could
work> If so, that's more a clocksource thing than a dynticks/hrtimer thing,
isn't it?

-
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/