linux-kernel - Re: [tip:timers/core] timekeeping: Increase granularity of read_persistent

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]

Message-ID: <20090825082612.GA17692@elte.hu>
Date:	Tue, 25 Aug 2009 10:26:12 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Paul Mackerras <paulus@...ba.org>
Cc:	Martin Schwidefsky <schwidefsky@...ibm.com>, dwalker@...o99.com,
	mingo@...hat.com, hpa@...or.com, linux-kernel@...r.kernel.org,
	johnstul@...ibm.com, tglx@...utronix.de,
	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:timers/core] timekeeping: Increase granularity of
	read_persistent_clock()

* Paul Mackerras <paulus@...ba.org> wrote:

> > I actually start regretting that i do rebases too frequently - 
> > some people (not you really, but you gave me the perfect example 
> > to reply to) want more and seem to think they are _entitled_ to 
> > rebases and are entitled to backmerges. The thing is, rebases 
> > are not free. They are risky and error-prone, and they destroy 
> > Git history.
> 
> To be honest, I didn't think I was asking for a rebase of 
> something which was already cast in stone, since I didn't think 
> you would have cast a commit in stone before doing a build test on 
> powerpc.

I think there's a fundamental disconnect with reality here.

The thing is, as the maintainer of certain core kernel subsystems i 
_have to_ mirror and honor the system usage and hardware preferences 
of developers, testers and users. Those are predominantly x86 based 
currently. I cross-test to a lot of architectures because i'm nice 
but in practice it rarely matters.

(It goes beyond that btw: i try to test more common drivers within 
x86 too, etc.)

If you want to change that reality you can do it the old fashioned, 
fair way: build cool hardware, send more SDVs to kernel developers, 
make PowerPC more widely used, etc.

If i put more effort into testing what nobody uses i'd be doing a 
disservice to Linux - i'd disproportionately favor PowerPC just 
because you are a squeakier wheel.

I.e. please _earn_ your usage share, dont try to dicate it 
artificially ... It does not work the other way, you cannot force in 
the kernel space what PowerPC did not manage to achieve in the 
marketplace.

If you suggest that each and every subsystem maintainer who touches 
code that can be built on non-x86 architectures has to cross-build 
to 20+ architectures to be able to push out a tree, all the time, 
and has to rebase if this ever gets omitted, you are really defying 
reality and are hurting Linux.

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