linux-kernel - Re: [PATCH 06/20] early_res: seperate common memmap func from e820.c to fw

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: <20100322130530.GC12475@elte.hu>
Date:	Mon, 22 Mar 2010 14:05:30 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Paul Mackerras <paulus@...ba.org>
Cc:	David Miller <davem@...emloft.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	yinghai@...nel.org, benh@...nel.crashing.org, tglx@...utronix.de,
	hpa@...or.com, jbarnes@...tuousgeek.org, ebiederm@...ssion.com,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH 06/20] early_res: seperate common memmap func from e820.c
 to fw_memmap.c

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

> And I don't see the point of moving the x86 e820 stuff into the kernel 
> directory. [...]

I dont see the point of that either - that is a mistake. e820 is an x86 bios 
call and we shouldnt name a generic mechanism after that. e820 is absolutely 
messy and has no place anywhere beyond x86.

The main technical argument i see is 'early_res versus LMB'. Even there i'd 
prefer LMB from a technical quality POV.

> Well I personally don't mind if x86 uses early_res or whatever other code in 
> arch/x86 to handle the problems that arise from deficient firmware.  I just 
> don't see any value in converting powerpc or sparc64 over to using ~2000 
> lines of early_res/fw_memmap code where the existing ~500 lines of lmb code 
> is working just fine.

Lets put it this way then: do you see any point in PowerPC making use of a 10+ 
million lines of code kernel that is being mainly (80%+) financed, developed, 
tested and deployed by people who care about x86 mostly?

If yes then it seems like a pretty damn good deal to me for PowerPC to go 
beyond its narrow short-term self-interest and work towards generalizations 
more actively, and even consider touching its 500 lines of lmb code ...

I dont know how many times we've accomodated for non-x86 architectures in 
various pieces of kernel code.

Obviously if there's bloat affecting PowerPC then that can be addressed via 
technical measures. But we really shouldnt leave the slightly incompatible 
early allocators in place. (we shouldnt have let them get created in the first 
place, but that is water down the bridge.)

Thanks,

	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/