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: <20090825101742.GA26801@elte.hu>
Date:	Tue, 25 Aug 2009 12:17:42 +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:

> Ingo Molnar writes:
> 
> > 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.
> 
> Nice straw man, but I never said or even suggested anything like 
> that. :)

... but what you say in essence amounts to that. Every change to a 
file that is built on an architecture 'affects' that architecture so 
your arguments can be repeated for that one. It's a slippery slope 
built on a wrong premise.

I can only repeat what i said because i did not see you really 
counter the core of my argument (you snipped out much of my mail 
that details this and only replied to the last paragraph):

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

We should be (and are) testing what matters and 22 architectures 
must not be allowed to hold core kernel facilities hostage.

( Plus, as i said the current tip of timers/core was problematic for 
  other reasons as well, which amounts to a 'might need to be 
  rebased'. )

> I do think that it's reasonable to expect that a patch which 
> touches the architecture-specific code for some architecture gets 
> compiled for that architecture at least once before it gets set in 
> stone.  As far as I can tell, this didn't happen in the case of 
> Martin's patch that triggered this debate.

I've seen similar arguments for patches that didnt touch any 
architecture files but broke it via some other, less direct way.

Say that patch also touches arch/xtensa/. Can you cross-build to 
xtensa?

> Patches which touch multiple architecture's arch-specific code 
> should also get sent to the maintainers of the affected 
> architectures and the linux-arch mailing list.  I don't recall 
> seeing this patch on linux-arch, though I may have missed it (and 
> anyway that would be Martin's responsibility not yours, but it 
> does contribute to the sense of being blindsided).
> 
> More generally - if you don't have the resources to do regular 
> build testing for powerpc or other architectures, then publish a 
> testing branch and we'll get kisskb 
> (http://kisskb.ellerman.id.au/) to build a selection of configs 
> and architectures automatically.

Slowing down patches via buerocracy like that is not acceptable at 
all. Make developers care more about your architecture via natural 
means, not via buerocratic measures.

	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/