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: <alpine.LFD.2.02.1208221106010.1754@xanadu.home>
Date:	Wed, 22 Aug 2012 11:23:23 -0400 (EDT)
From:	Nicolas Pitre <nicolas.pitre@...aro.org>
To:	Arnd Bergmann <arnd@...db.de>
cc:	linux-arm-kernel@...ts.infradead.org,
	linaro-kernel@...ts.linaro.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] [RFC] ARM: multiplatform: rename all mach headers

On Wed, 22 Aug 2012, Arnd Bergmann wrote:

> I've created this series some time ago, and updated it now to
> v3.6-rc1. The idea is to get us a big step closer to the
> single zImage kernel across multiple ARM platforms by
> untangling the duplicate header file names.

Thanks for picking up this task.

> There are two branches available in the arm-soc tree:
> 
> 1. This series,
>    http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=shortlog;h=refs/heads/testing/mach-headers
>    This just moves header files around and changes most of the
>    files including them. There are a few remaining drivers
>    and platform files that keep including a generic file name
>    like <mach/uncompress.h>. It remains possible to do that,
>    and I've run extensive tests to ensure I did not break
>    anything with this. However, each of these instances means
>    that there is something that stops working when you get to
>    the real multiplatform kernel and we still need to deal
>    with them one by one.

The content of <mach/uncompress.h> is fundamentally machine or SOC 
specific.  We already know it is generally incompatible with a multi 
platform kernel.  So the best way to deal with this at the moment is 
probably to just provide a dummy uncompress.h with empty stubs whenever 
CONFIG_ARCH_MULTIPLATFORM is selected.  The effect from this is that 
there wouldn't be any "Uncompressing the kernel... Done" output anymore, 
which should be an acceptable compromise until a better solution is 
found.

One problem is that some (very few) machines define a method in that 
file to keep a hardware watchdog alive.  This might not be the case for 
all the intended targets to gather in a single kernel binary image 
though.

Another issue is the fact that some platforms do very ugly 
layer-violating hacks where the decompressor selects a serial port for 
early output and then store that selection in some arbitrary memory 
location for the main kernel to blindly use, making the decompressor 
mandatory.  OMAP and Davinci are prime example of such "abuse" which 
would need to be fixed.


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ